March 20, 2017 | Written by: Donald Cronin
Categorized: DevOps | How-tos
Share this post:
Over the past year, I focused on providing better data for the DevOps process. Data-driven is the wave of the future, and the wealth of data that is in code repos, issue-tracking systems, and build systems can be used to improve the ability to deliver apps faster and with greater quality.
Three areas of focus are key:
- Prediction models for the error proneness of files in your app and files from open source projects. These models help you better understand the potential risk in your code base.
- Team interaction graphs, which demonstrate how your team is interacting through code and issues. With this information, you can analyze changes over time from your team and understand the areas that are needed for team growth.
- Tracking code coverage, unit and functional tests, and security scans to determine the risk that is associated with deployments.
My team takes advantage of these metrics by using the IBM® Bluemix® Continuous Delivery service. With that service, the team can focus its limited time on the areas that provide the most benefit, and squad leads better understand the workings of the team and areas for improvement.
You can try these capabilities at bluemix.net/devops. The “Deployment Risk Analytics with GitHub and Jenkins” template and the “Developer Insights and Team Dynamics with GitHub and JIRA” template are good starting points.
Prediction models for error proneness
This graph demonstrates the error proneness predictions for a typical open source project. In this case, a zookeeper project is being analyzed. The center of the circle is the root of the repo. Progressing outwards, you can see the probabilities of error for different directories and files. The center represents the computed error probability. The redness of individual blocks shows the relative probabilities. This graph gives you an at-a-glance understanding of error probabilities for your projects.
Team interaction graphs
These graphs represent the interactions of code additions and deletions across your project. From these graphs, you can get a quick understanding of the changes that are being made and who is making those changes. My team uses this graph at the end of sprint to understand the changes that are occurring. The graph also helps to generate the right discussion among team members. At a higher level, I can see the changes at a macro level and look for areas where I need people to become skilled in an area.
Tracking code coverage, tests, and scans to determine deployment risk
When you’re faced with the decision to deploy updates to production, you need a place where you can quickly see whether any of your policies were violated. In this case, you can see that the coverage of testing does not meet the defined policy. You can set up gates in both Jenkins and Delivery Pipeline to stop deployments when policies are not followed.
I hope these insights can help your development team improve its overall process. My team summarizes some of these insights into a set of development practices that are a good place to start looking for improvements.