Measuring results is challenging in any field as it might give you the outcome that is Good or it shows you unexpected things with failures. DevOps is a Culture Transformation process and it is a long process of almost 3–5 years. There is a risk as well as opportunity in the entire exercise.
How to measure success? We need data to measure the performance of the entire Culture transformation initiative.
In this article, we will see some aspects of how we can measure success for the culture transformation exercise.
Metrics for DevOps success
Monitor metrics or KPIs to measure the success of the DevOps initiative and gain confidence in higher management in the organization. DevOps metrics also help to find out the Maturity of the DevOps transformation exercise. It helps to locate the position in the maturity model as well.
Let’s see some of the important metrics.
Culture: Culture Transformation is the main objective of DevOps practices implementation. Continuous practices implementation results in Continuous Improvements and Continuous Innovations more often than less. It helps in agile development practices where 3–4 development cycles are available and the release candidate has to be available by the end of sprint time.
Following are some of the indicators:
- Happy team
- Happy customer
- Employee attrition rate
Automation: Automation is not the only thing but it is extremely important in the entire transformation process. Automation removes manual activities that are repetitive and cumbersome.
Following are some of the indicators:
- Development time in a sprint
- Verification and validation time in a sprint
- Build verification time in a sprint
- Deployment time in a sprint
- Overall time from planning to deployment
- Manual and automated reviews/approvals
Build and deployment time: How much actual build and deployment time is taken with existing processes and tools? Both the parameters are easy to monitor and evaluate and hence, the comparison helps to convince the development and operations team.
Lead time: Lead time is about time that is spent from Bug fix to deploying it to the production environment or from new feature implementation to making it available to end-users. Long Lead time and Short Lead time indicate ineffective and effective processes for end-to-end operations.
Quality: Quality of code is as important as faster time to market.
- Static code analysis
- Bugs/Issues (Critical/blocker issues, Major issues, Minor issues)
- Security vulnerabilities (Critical/blocker issues, Major issues, Minor issues)
- Code smells — Coding practices (Critical/blocker issues, Major issues, Minor issues)
- Automated unit tests coverage percentage
- Automated functional tests coverage percentage
- Automated regression tests
- Automated integration tests
- Automated security tests
- Static application security testing
- Dynamic application security testing
- Test data, stubs, test environment availability, test summary reports, notifications
- Quality gates related to coding standards, unit test coverage, and security/audit
- Severity of issues, resolution time, and cost in terms of time, money, and productivity
- Environment-related issues and configuration management related issues
Availability: High availability and fault tolerance is important in today’s competitive market. It is important to use cloud resources and configure resources in a way that applications are always available and easy to roll back with minimum downtime. Rollback time can be a critical indicator. In Azure App Services, there is a concept called deployment slots that allows rollback within a few seconds. Such cloud-native features or some other configuration such as deployment in multiple regions, load balancers, horizontal and vertical scaling, and so on.
If you need an answer to “How is DevOps going within your organization?” or any help in measuring just how well it is going, then you can refer to this article and formulate your own DevOps KPIs.
Hope this was helpful.