DevOps allows you to measure several important metrics in order to maximize the efficiency of developing, deploying, and releasing software. But one important metric that has been overlooked as a KPI is release frequency. The question in our minds is this: should it be? Here are some thoughts and facts why we believe this is the right thing to do.
What is deployment vs. release?
Deploying and releasing a software are two separate things. While a deployment marks the installation of software in an environment, a release is when we make the features available to our customers. In a DevOps culture, developers often decouple software deployments and releases, creating several unique benefits.
Benefits of decoupling
The primary benefit of decoupling software deployments and releases is that it makes releasing new features less stressful. When you deploy features prior to releasing them to customers, you can time your release frequency based on when it’s most useful from a business stage.
You can also take advantage of two release techniques to rollback the new feature if necessary. Canary release technique reduces the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody. Blue-green deployment pattern does something similar by creating two nearly identical production environments, allowing you to rapidly rollback by switching between the two if need be.
The case for measuring release frequency
The State of DevOps report, a great resource about DevOps adoption within the industry, identified deployment frequency as one of the pivotal KPI’s that signal DevOps maturity. However, while they define deployment as “deploying to production,” they do not mention release frequency as a KPI.
Measuring release frequency as a separate metric is vital given that deployments and releases are two separate concepts with different motivations.
If you can see the metrics of both deployment frequency and release frequency, then you can better understand what proportion of software that is deployed ultimately gets released. And at the end of the day, software that doesn’t get released to end-users never gets used, causing you to miss out on potential feedback and return on investment.
0 comments