Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Why should we start measuring the Release Frequency?

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.



Log in or Sign up to comment
AUG Leaders

Atlassian Community Events