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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>> 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: [email protected]
>>>
>>>
>>>
>>
>>
>> --
>>
>>
>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando*
>> Software Architect; WSO2 Inc.; http://wso2.com
>>
>>
>>
>> * Member; Apache Software Foundation; http://apache.org
>> <http://apache.org>E-mail: senaka AT wso2.com <http://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
>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
>>
>
>
>
> --
>
> * Aruna Sujith Karunarathna* | Software Engineer
> WSO2, Inc | lean. enterprise. middleware.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 71 9040362 | Work: +94 112145345
> Email: [email protected] | Web: www.wso2.com
>
>



-- 
Denuwanthi De Silva
Software Engineer;
WSO2 Inc.; http://wso2.com,
Email: [email protected]
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to