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 <[email protected]> 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 <[email protected]>
> 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 <[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]
>>
>>
>>
>
>
> --
>
>
> *[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
>



-- 
Thanks
/subash

*Subash Chaturanga*
Senior Software Engineer & Lead WSO2 Governance Registry
Platform TG; WSO2 Inc. http://wso2.com
Contact:
email: [email protected]
blog:  http://subashsdm.blogspot.com/
twitter: @subash89
phone: +9477 2225922
Lean . Enterprise . Middleware
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to