Re: [Dev] G-Reg 5.0.0 new feature : Adding lifecycle state aware dashboards for services

[Subash Chaturanga]

Hi
Yes +1 for do an online research on governance space + governance vendors.
It will give us a better insight on what users currently asking for.


On Mon, Aug 4, 2014 at 4:07 PM, Senaka Fernando  wrote:

> Hi Denuwanth, Aruna,
>
> At a high-level you'll are headed in the right direction.
>
> Some of the gadgets we did were related to C5 project (ex:- the Jenkins
> Build Rules). I don't think its very relevant for services. And, remember
> we use the 80%-20% model. Unless 80% of the people who use this
> functionality need this, it is not required. Therefore, things related to
> automation might not also be relevant. I would remove those as well.
>
> Also, separately, if you can do some online research into what kinds of
> statistics people need with regards to the services they develop, we should
> be able to identify some other useful gadgets.
>
> Thanks,
> Senaka.
>
>
> On Mon, Aug 4, 2014 at 9:42 AM, Denuwanthi De Silva 
> wrote:
>
>> Hi Senaka,
>>
>> Thank you for the explanation.
>> The redmine issue is updated at [1].
>>
>> I had an off line discussion with Aruna, and went through the provided
>> documentation [2]. As you mentioned they use BAM to produce the relevant
>> statistics reports.
>> They provide several gadgets, which I separated according to our LC
>> states. Any suggestions on those selections are welcome.
>>
>> *Development State*:
>>
>>- Summary of Commits
>>- Summary of the Project
>>- Details of Commits
>>- Top Five Contributors
>>- Bamboo Build Success Rate
>>- Bamboo Latest Build Status
>>- Commits of Latest Build
>>
>> *Testing State:*
>>
>>- Emma Coverage Status
>>- Emma Package Details
>>- Emma Test Coverage
>>- Overall Test Status
>>- Automation Test Status
>>- Test Status by Priority
>>- Test Status by Owners
>>- Automation Test Coverage
>>
>> *Production State:*
>>
>>- Should be decided (Ex: run time request/response stats). Any other
>>suggestions on what kind of details to show here?
>>
>> Additionally they have following two gadgets. Do we need them in our
>> scenario?
>>
>>- Jenkins Build Rules Details
>>- Jenkins Build Rules Stat
>>
>> As I understood, most of these analytics are suitable in project level.
>> So, what kind of details would be suitable to show in service-level?
>>
>>
>> [1] https://redmine.wso2.com/issues/3073
>> [2]
>> https://docs.google.com/a/wso2.com/document/d/1VGQ91N3KHestuPR6_uAuFIWCfdbRslFBbOobeZ8mdnc/edit#
>>
>> Thanks,
>>
>>
>> On Mon, Aug 4, 2014 at 10:29 AM, Aruna Karunarathna 
>> wrote:
>>
>>> Hi Denuwanthi,
>>>
>>> As Senaka has mentioned we did some Gadgets for C5 Dev Governance
>>> project.You can get the idea about the Dashboards we did for the C5 Dev
>>> Governance Project by referencing  this doc. [1]
>>> Source Repos for the Data Collectors and Dashboards are available at
>>> [2], [3].
>>>
>>> If you need further assistance please drop a mail or we can have a
>>> offline chat.
>>>
>>>
>>> [1].
>>> https://docs.google.com/a/wso2.com/document/d/1VGQ91N3KHestuPR6_uAuFIWCfdbRslFBbOobeZ8mdnc/edit#
>>> [2]. https://github.com/arunasujith/governance-data-collector
>>> [3]. https://github.com/arunasujith/wso2_devgov_dashboards
>>>
>>> Regards,
>>> Aruna
>>>
>>>
>>>
>>> On Fri, Aug 1, 2014 at 9:05 PM, Senaka Fernando  wrote:
>>>
 Hi Denuwanthi,

 Firstly, this was discussed a little earlier, and apologies for not
 updating the Redmine issue with this information. Now that you are working
 on this issue, please update it with this info.

 The idea is that we will push all types of analytics into BAM and
 produce reports out of that. This is structurally similar to what's done in
 API Manager, but the gadgets and layouts are obviously different. Aruna et
 al built some of these UIs already. When this gets integrated into G-Reg,
 we need to focus on a few things.

 Firstly, some analytics do not make sense at service-level, but some
 do. If so, we need to find ways to display them depending on the level of
 granularity that we have chose. If its at project-level, we will probably
 hide the gadget or show blank information. If its at service-level, we will
 figure out the project to which it belongs and then populate the relevant
 project assets.

 But, the concept of service-level and project-level both need to be
 supported. And, some gadgets obviously, will get reused. For these kinds of
 gadgets, we will need to get them to display data on the level of
 granularity (i.e. service or project).

 So, as you might be wondering, we should be able to tell the gadgets
 (or the entire dashboard), what level to display (whether it is service or
 project) in addition to what to display. This is what we need to figure
 out. AFAIU, we can use the same dashboard but have two attributes to
 capture name of asset and type of asset (i.e. service or project). Another
>>>

Re: [Dev] G-Reg 5.0.0 new feature : Adding lifecycle state aware dashboards for services

[Senaka Fernando]

Hi Denuwanth, Aruna,

At a high-level you'll are headed in the right direction.

Some of the gadgets we did were related to C5 project (ex:- the Jenkins
Build Rules). I don't think its very relevant for services. And, remember
we use the 80%-20% model. Unless 80% of the people who use this
functionality need this, it is not required. Therefore, things related to
automation might not also be relevant. I would remove those as well.

Also, separately, if you can do some online research into what kinds of
statistics people need with regards to the services they develop, we should
be able to identify some other useful gadgets.

Thanks,
Senaka.


On Mon, Aug 4, 2014 at 9:42 AM, Denuwanthi De Silva 
wrote:

> Hi Senaka,
>
> Thank you for the explanation.
> The redmine issue is updated at [1].
>
> I had an off line discussion with Aruna, and went through the provided
> documentation [2]. As you mentioned they use BAM to produce the relevant
> statistics reports.
> They provide several gadgets, which I separated according to our LC
> states. Any suggestions on those selections are welcome.
>
> *Development State*:
>
>- Summary of Commits
>- Summary of the Project
>- Details of Commits
>- Top Five Contributors
>- Bamboo Build Success Rate
>- Bamboo Latest Build Status
>- Commits of Latest Build
>
> *Testing State:*
>
>- Emma Coverage Status
>- Emma Package Details
>- Emma Test Coverage
>- Overall Test Status
>- Automation Test Status
>- Test Status by Priority
>- Test Status by Owners
>- Automation Test Coverage
>
> *Production State:*
>
>- Should be decided (Ex: run time request/response stats). Any other
>suggestions on what kind of details to show here?
>
> Additionally they have following two gadgets. Do we need them in our
> scenario?
>
>- Jenkins Build Rules Details
>- Jenkins Build Rules Stat
>
> As I understood, most of these analytics are suitable in project level.
> So, what kind of details would be suitable to show in service-level?
>
>
> [1] https://redmine.wso2.com/issues/3073
> [2]
> https://docs.google.com/a/wso2.com/document/d/1VGQ91N3KHestuPR6_uAuFIWCfdbRslFBbOobeZ8mdnc/edit#
>
> Thanks,
>
>
> On Mon, Aug 4, 2014 at 10:29 AM, Aruna Karunarathna 
> wrote:
>
>> Hi Denuwanthi,
>>
>> As Senaka has mentioned we did some Gadgets for C5 Dev Governance
>> project.You can get the idea about the Dashboards we did for the C5 Dev
>> Governance Project by referencing  this doc. [1]
>> Source Repos for the Data Collectors and Dashboards are available at [2],
>> [3].
>>
>> If you need further assistance please drop a mail or we can have a
>> offline chat.
>>
>>
>> [1].
>> https://docs.google.com/a/wso2.com/document/d/1VGQ91N3KHestuPR6_uAuFIWCfdbRslFBbOobeZ8mdnc/edit#
>> [2]. https://github.com/arunasujith/governance-data-collector
>> [3]. https://github.com/arunasujith/wso2_devgov_dashboards
>>
>> Regards,
>> Aruna
>>
>>
>>
>> On Fri, Aug 1, 2014 at 9:05 PM, Senaka Fernando  wrote:
>>
>>> Hi Denuwanthi,
>>>
>>> Firstly, this was discussed a little earlier, and apologies for not
>>> updating the Redmine issue with this information. Now that you are working
>>> on this issue, please update it with this info.
>>>
>>> The idea is that we will push all types of analytics into BAM and
>>> produce reports out of that. This is structurally similar to what's done in
>>> API Manager, but the gadgets and layouts are obviously different. Aruna et
>>> al built some of these UIs already. When this gets integrated into G-Reg,
>>> we need to focus on a few things.
>>>
>>> Firstly, some analytics do not make sense at service-level, but some do.
>>> If so, we need to find ways to display them depending on the level of
>>> granularity that we have chose. If its at project-level, we will probably
>>> hide the gadget or show blank information. If its at service-level, we will
>>> figure out the project to which it belongs and then populate the relevant
>>> project assets.
>>>
>>> But, the concept of service-level and project-level both need to be
>>> supported. And, some gadgets obviously, will get reused. For these kinds of
>>> gadgets, we will need to get them to display data on the level of
>>> granularity (i.e. service or project).
>>>
>>> So, as you might be wondering, we should be able to tell the gadgets (or
>>> the entire dashboard), what level to display (whether it is service or
>>> project) in addition to what to display. This is what we need to figure
>>> out. AFAIU, we can use the same dashboard but have two attributes to
>>> capture name of asset and type of asset (i.e. service or project). Another
>>> option is to use separate dashboards for service and project and use just
>>> the name attribute. This is something we need to decide. Having the same
>>> dashboard IMO will allow us to switch between services and projects without
>>> having to reload the dashboard, which is somewhat attractive to the end
>>> user. But, this might also need some he

Re: [Dev] G-Reg 5.0.0 new feature : Adding lifecycle state aware dashboards for services

[Denuwanthi De Silva]

Hi Senaka,

Thank you for the explanation.
The redmine issue is updated at [1].

I had an off line discussion with Aruna, and went through the provided
documentation [2]. As you mentioned they use BAM to produce the relevant
statistics reports.
They provide several gadgets, which I separated according to our LC states.
Any suggestions on those selections are welcome.

*Development State*:

   - Summary of Commits
   - Summary of the Project
   - Details of Commits
   - Top Five Contributors
   - Bamboo Build Success Rate
   - Bamboo Latest Build Status
   - Commits of Latest Build

*Testing State:*

   - Emma Coverage Status
   - Emma Package Details
   - Emma Test Coverage
   - Overall Test Status
   - Automation Test Status
   - Test Status by Priority
   - Test Status by Owners
   - Automation Test Coverage

*Production State:*

   - Should be decided (Ex: run time request/response stats). Any other
   suggestions on what kind of details to show here?

Additionally they have following two gadgets. Do we need them in our
scenario?

   - Jenkins Build Rules Details
   - Jenkins Build Rules Stat

As I understood, most of these analytics are suitable in project level.
So, what kind of details would be suitable to show in service-level?


[1] https://redmine.wso2.com/issues/3073
[2]
https://docs.google.com/a/wso2.com/document/d/1VGQ91N3KHestuPR6_uAuFIWCfdbRslFBbOobeZ8mdnc/edit#

Thanks,


On Mon, Aug 4, 2014 at 10:29 AM, Aruna Karunarathna  wrote:

> Hi Denuwanthi,
>
> As Senaka has mentioned we did some Gadgets for C5 Dev Governance
> project.You can get the idea about the Dashboards we did for the C5 Dev
> Governance Project by referencing  this doc. [1]
> Source Repos for the Data Collectors and Dashboards are available at [2],
> [3].
>
> If you need further assistance please drop a mail or we can have a offline
> chat.
>
>
> [1].
> https://docs.google.com/a/wso2.com/document/d/1VGQ91N3KHestuPR6_uAuFIWCfdbRslFBbOobeZ8mdnc/edit#
> [2]. https://github.com/arunasujith/governance-data-collector
> [3]. https://github.com/arunasujith/wso2_devgov_dashboards
>
> Regards,
> Aruna
>
>
>
> On Fri, Aug 1, 2014 at 9:05 PM, Senaka Fernando  wrote:
>
>> Hi Denuwanthi,
>>
>> Firstly, this was discussed a little earlier, and apologies for not
>> updating the Redmine issue with this information. Now that you are working
>> on this issue, please update it with this info.
>>
>> The idea is that we will push all types of analytics into BAM and produce
>> reports out of that. This is structurally similar to what's done in API
>> Manager, but the gadgets and layouts are obviously different. Aruna et al
>> built some of these UIs already. When this gets integrated into G-Reg, we
>> need to focus on a few things.
>>
>> Firstly, some analytics do not make sense at service-level, but some do.
>> If so, we need to find ways to display them depending on the level of
>> granularity that we have chose. If its at project-level, we will probably
>> hide the gadget or show blank information. If its at service-level, we will
>> figure out the project to which it belongs and then populate the relevant
>> project assets.
>>
>> But, the concept of service-level and project-level both need to be
>> supported. And, some gadgets obviously, will get reused. For these kinds of
>> gadgets, we will need to get them to display data on the level of
>> granularity (i.e. service or project).
>>
>> So, as you might be wondering, we should be able to tell the gadgets (or
>> the entire dashboard), what level to display (whether it is service or
>> project) in addition to what to display. This is what we need to figure
>> out. AFAIU, we can use the same dashboard but have two attributes to
>> capture name of asset and type of asset (i.e. service or project). Another
>> option is to use separate dashboards for service and project and use just
>> the name attribute. This is something we need to decide. Having the same
>> dashboard IMO will allow us to switch between services and projects without
>> having to reload the dashboard, which is somewhat attractive to the end
>> user. But, this might also need some help from the BAM end.
>>
>> Thanks,
>> Senaka.
>>
>>
>> On Fri, Aug 1, 2014 at 7:55 AM, Denuwanthi De Silva 
>> wrote:
>>
>>> Hi Senaka et. al,
>>>
>>> I'm working on $subject. The corresponding Redmine link is at [1]
>>>
>>> *Current Implementation*
>>> As for now, G-reg only support, moving from several lifecycle states
>>> (Development, Testing. Production) for services. It supports validation of
>>> each state via checklists.
>>>
>>> *New Feature*
>>> Now, we plan to support a lifecycle state aware dashboards/view for
>>> services.
>>> That is, for each lifecycle state of a service, we plan to provide a
>>> customized view corresponding to that state.
>>> Ex: Details
>>>
>>>- Development state - The dashboard can show contributers, source
>>>repository URLs, no of commits, highest committer, stats related to its
>>>source control system e

Re: [Dev] G-Reg 5.0.0 new feature : Adding lifecycle state aware dashboards for services

[Aruna Karunarathna]

Hi Denuwanthi,

As Senaka has mentioned we did some Gadgets for C5 Dev Governance
project.You can get the idea about the Dashboards we did for the C5 Dev
Governance Project by referencing  this doc. [1]
Source Repos for the Data Collectors and Dashboards are available at [2],
[3].

If you need further assistance please drop a mail or we can have a offline
chat.


[1].
https://docs.google.com/a/wso2.com/document/d/1VGQ91N3KHestuPR6_uAuFIWCfdbRslFBbOobeZ8mdnc/edit#
[2]. https://github.com/arunasujith/governance-data-collector
[3]. https://github.com/arunasujith/wso2_devgov_dashboards

Regards,
Aruna



On Fri, Aug 1, 2014 at 9:05 PM, Senaka Fernando  wrote:

> Hi Denuwanthi,
>
> Firstly, this was discussed a little earlier, and apologies for not
> updating the Redmine issue with this information. Now that you are working
> on this issue, please update it with this info.
>
> The idea is that we will push all types of analytics into BAM and produce
> reports out of that. This is structurally similar to what's done in API
> Manager, but the gadgets and layouts are obviously different. Aruna et al
> built some of these UIs already. When this gets integrated into G-Reg, we
> need to focus on a few things.
>
> Firstly, some analytics do not make sense at service-level, but some do.
> If so, we need to find ways to display them depending on the level of
> granularity that we have chose. If its at project-level, we will probably
> hide the gadget or show blank information. If its at service-level, we will
> figure out the project to which it belongs and then populate the relevant
> project assets.
>
> But, the concept of service-level and project-level both need to be
> supported. And, some gadgets obviously, will get reused. For these kinds of
> gadgets, we will need to get them to display data on the level of
> granularity (i.e. service or project).
>
> So, as you might be wondering, we should be able to tell the gadgets (or
> the entire dashboard), what level to display (whether it is service or
> project) in addition to what to display. This is what we need to figure
> out. AFAIU, we can use the same dashboard but have two attributes to
> capture name of asset and type of asset (i.e. service or project). Another
> option is to use separate dashboards for service and project and use just
> the name attribute. This is something we need to decide. Having the same
> dashboard IMO will allow us to switch between services and projects without
> having to reload the dashboard, which is somewhat attractive to the end
> user. But, this might also need some help from the BAM end.
>
> Thanks,
> Senaka.
>
>
> On Fri, Aug 1, 2014 at 7:55 AM, Denuwanthi De Silva 
> wrote:
>
>> Hi Senaka et. al,
>>
>> I'm working on $subject. The corresponding Redmine link is at [1]
>>
>> *Current Implementation*
>> As for now, G-reg only support, moving from several lifecycle states
>> (Development, Testing. Production) for services. It supports validation of
>> each state via checklists.
>>
>> *New Feature*
>> Now, we plan to support a lifecycle state aware dashboards/view for
>> services.
>> That is, for each lifecycle state of a service, we plan to provide a
>> customized view corresponding to that state.
>> Ex: Details
>>
>>- Development state - The dashboard can show contributers, source
>>repository URLs, no of commits, highest committer, stats related to its
>>source control system etc
>>
>>
>>- Testing state - The dashboard can show jenkins builder test
>>results, etc.
>>
>>
>>- Production state - (have to decide on what stats to show) showing
>>run time request/response stats for the service is one option.
>>
>>
>> *Challenges*
>> But, if we are going to provide this in service level, for each service
>> we will have to provide these details.
>>
>>-  So, where should we keep all those details (described above) ?
>>
>>
>>- Is it ideal to provide this state aware dashboards/views per
>>service or should we go to an approach like  using the concept of
>>'project'  (discussed in Unified Governance Model) which will contain
>>several services & handle the lifecycle state aware details (described
>>above), on 'project' level?
>>
>>
>> Is there anything need to be added or removed from above?
>>
>>
>> [1] https://redmine.wso2.com/issues/3073
>>
>>
>> Thanks,
>> --
>> Denuwanthi De Silva
>> Software Engineer;
>> WSO2 Inc.; http://wso2.com,
>> Email: denuwan...@wso2.com
>>
>>
>>
>
>
> --
>
>
> *[image: http://wso2.com]  Senaka Fernando*
> Software Architect; WSO2 Inc.; http://wso2.com
>
>
>
> * Member; Apache Software Foundation; http://apache.org
> E-mail: senaka AT wso2.com **P: +1
> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*;
>
>
> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In:
> http://linkedin.com/in/senakafernando
> *Lean . Enterprise . Middleware
>



-- 

*Aruna Sujith Kar

Re: [Dev] G-Reg 5.0.0 new feature : Adding lifecycle state aware dashboards for services

[Senaka Fernando]

Hi Denuwanthi,

Firstly, this was discussed a little earlier, and apologies for not
updating the Redmine issue with this information. Now that you are working
on this issue, please update it with this info.

The idea is that we will push all types of analytics into BAM and produce
reports out of that. This is structurally similar to what's done in API
Manager, but the gadgets and layouts are obviously different. Aruna et al
built some of these UIs already. When this gets integrated into G-Reg, we
need to focus on a few things.

Firstly, some analytics do not make sense at service-level, but some do. If
so, we need to find ways to display them depending on the level of
granularity that we have chose. If its at project-level, we will probably
hide the gadget or show blank information. If its at service-level, we will
figure out the project to which it belongs and then populate the relevant
project assets.

But, the concept of service-level and project-level both need to be
supported. And, some gadgets obviously, will get reused. For these kinds of
gadgets, we will need to get them to display data on the level of
granularity (i.e. service or project).

So, as you might be wondering, we should be able to tell the gadgets (or
the entire dashboard), what level to display (whether it is service or
project) in addition to what to display. This is what we need to figure
out. AFAIU, we can use the same dashboard but have two attributes to
capture name of asset and type of asset (i.e. service or project). Another
option is to use separate dashboards for service and project and use just
the name attribute. This is something we need to decide. Having the same
dashboard IMO will allow us to switch between services and projects without
having to reload the dashboard, which is somewhat attractive to the end
user. But, this might also need some help from the BAM end.

Thanks,
Senaka.


On Fri, Aug 1, 2014 at 7:55 AM, Denuwanthi De Silva 
wrote:

> Hi Senaka et. al,
>
> I'm working on $subject. The corresponding Redmine link is at [1]
>
> *Current Implementation*
> As for now, G-reg only support, moving from several lifecycle states
> (Development, Testing. Production) for services. It supports validation of
> each state via checklists.
>
> *New Feature*
> Now, we plan to support a lifecycle state aware dashboards/view for
> services.
> That is, for each lifecycle state of a service, we plan to provide a
> customized view corresponding to that state.
> Ex: Details
>
>- Development state - The dashboard can show contributers, source
>repository URLs, no of commits, highest committer, stats related to its
>source control system etc
>
>
>- Testing state - The dashboard can show jenkins builder test results,
>etc.
>
>
>- Production state - (have to decide on what stats to show) showing
>run time request/response stats for the service is one option.
>
>
> *Challenges*
> But, if we are going to provide this in service level, for each service we
> will have to provide these details.
>
>-  So, where should we keep all those details (described above) ?
>
>
>- Is it ideal to provide this state aware dashboards/views per service
>or should we go to an approach like  using the concept of  'project'
>(discussed in Unified Governance Model) which will contain several services
>& handle the lifecycle state aware details (described above), on 'project'
>level?
>
>
> Is there anything need to be added or removed from above?
>
>
> [1] https://redmine.wso2.com/issues/3073
>
>
> Thanks,
> --
> Denuwanthi De Silva
> Software Engineer;
> WSO2 Inc.; http://wso2.com,
> Email: denuwan...@wso2.com
>
>
>


-- 


*[image: http://wso2.com]  Senaka Fernando*
Software Architect; WSO2 Inc.; http://wso2.com



* Member; Apache Software Foundation; http://apache.org
E-mail: senaka AT wso2.com **P: +1 408
754 7388; ext: 51736*;


*M: +44 782 741 1966 Linked-In: http://linkedin.com/in/senakafernando
*Lean . Enterprise . Middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] G-Reg 5.0.0 new feature : Adding lifecycle state aware dashboards for services

[Denuwanthi De Silva]

Hi Senaka et. al,

I'm working on $subject. The corresponding Redmine link is at [1]

*Current Implementation*
As for now, G-reg only support, moving from several lifecycle states
(Development, Testing. Production) for services. It supports validation of
each state via checklists.

*New Feature*
Now, we plan to support a lifecycle state aware dashboards/view for
services.
That is, for each lifecycle state of a service, we plan to provide a
customized view corresponding to that state.
Ex: Details

   - Development state - The dashboard can show contributers, source
   repository URLs, no of commits, highest committer, stats related to its
   source control system etc


   - Testing state - The dashboard can show jenkins builder test results,
   etc.


   - Production state - (have to decide on what stats to show) showing run
   time request/response stats for the service is one option.


*Challenges*
But, if we are going to provide this in service level, for each service we
will have to provide these details.

   -  So, where should we keep all those details (described above) ?


   - Is it ideal to provide this state aware dashboards/views per service
   or should we go to an approach like  using the concept of  'project'
   (discussed in Unified Governance Model) which will contain several services
   & handle the lifecycle state aware details (described above), on 'project'
   level?


Is there anything need to be added or removed from above?


[1] https://redmine.wso2.com/issues/3073


Thanks,
-- 
Denuwanthi De Silva
Software Engineer;
WSO2 Inc.; http://wso2.com,
Email: denuwan...@wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev