Re: [Dev] G-Reg 5.0.0 new feature : Adding lifecycle state aware dashboards for services
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 denuwan...@wso2.com 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 ar...@wso2.com 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 sen...@wso2.com 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 denuwan...@wso2.com wrote: Hi Senaka et. al, I'm working
Re: [Dev] G-Reg 5.0.0 new feature : Adding lifecycle state aware dashboards for services
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 sen...@wso2.com 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 denuwan...@wso2.com 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 ar...@wso2.com 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 sen...@wso2.com 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,
Re: [Dev] G-Reg 5.0.0 new feature : Adding lifecycle state aware dashboards for services
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 sen...@wso2.com 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 denuwan...@wso2.com 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] http://wso2.com Senaka Fernando* Software Architect; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-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
[Dev] G-Reg 5.0.0 new feature : Adding lifecycle state aware dashboards for services
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
Re: [Dev] G-Reg 5.0.0 new feature : Adding lifecycle state aware dashboards for services
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 denuwan...@wso2.com 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] http://wso2.com Senaka Fernando* Software Architect; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388; ext: 51736*; *M: +44 782 741 1966 Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
