The book Accelerate by Nicole Forsgren, Jez Humble & Gene Kim provides a de-facto standard on how to measure development efficiency, supported by clear scientific findings. It identifies four key metrics that support software delivery performance, namely:
- Lead Time - how long does it take to go from code committed to code successfully running in production
- Deployment Frequency - how often your software team deploy changes to production
- Mean Time to Restore (MTTR) - how long it takes to resolve or rollback an error in production
- Change Fail Percentage - what percentage of changes to production (software releases and configuration changes) fail
By balancing tempo (Lead Time, Deployment Frequency) with stability metrics, it is ensured that increased speed does not result in suffering quality.
Metrics provides a powerful way to store time-related information and evaluate them from different contexts, e.g. dashboards. They can be filled very intuitively using the Integration API with the inboundMetrics processor.
Lead Time can be typically obtained from a tool like JIRA. On ticket or story level, it captures information on the starting time (typically a transition from READY into IN WORK) and when it has been finished. After mapping your JIRA project to the Team or Microservice Fact Sheet (see Data Model), the difference can be easily calculated and store in Metrics.
Deployment Frequency can be measured with help of the out-of-the-box CI/CD integration. Every deployment just increases the counter for the specific microservices, making a Deployment Frequency dashboard a quick win when implementing Microservice Intelligence,
The ideal end-to-end way to obtain MTTR KPIs is from a support system like Zendesk. With its help, major bugs observed by the customers can be tracked from initial reporting to complete resolution. Obviously, this requires a consistent mapping of microservices or product areas into the support system. Alternatively, recovery data can be fetched from systems like JIRA as well.
The simplest way to measure Change Fail Percentage is to look into your CI/CD builds, reporting on how often a build succeeds or fails. More sophisticated, if you capture information on regression in your support or ticketing system, it can be measured how often you are introducing a bug into production (even if the build succeeds).
Updated about 2 months ago