Deployment Frequency Explained (DORA metric)



One of the crucial tasks of the development and DevOps teams is to constantly deliver more value to the clients - more frequently and with more quality. Different practices have been introduced aiming to make engineering teams more efficient and agile in the software development process. For the software teams, it is very important to identify the blockers in the software delivery process and to optimize the value stream. 

In this article we elaborate the Deployment Frequency metrics, one of the key DORA metrics. 

DORA Metrics - Quick Introduction 

As a result of the DevOps acceleration survey – in 2015 Google established the program called DORA (DevOps Research and Assessment) group. In 2018 they published their study Accelerate introducing the DORA Metrics – a concept that defines 4 key metrics that can distinguish the high-performance development teams from the average ones: 

  • Deployment Frequency (DF) – measures the frequency at which code is deployed successfully to a production environment. Engineering teams tend to deliver new features to clients as soon as possible, so this metric is useful to understand how frequently that happens.
  • Lead Time for Changes (LTFC) – this metric shows how long it takes for a change to appear in the production environment, by looking at the average time between the first commit made in the dev environment and when that feature is successfully running in production.
  • Mean Time to Recovery (MTTR) – measures the time needed for the system to recover from an incident in production. To improve the MTTR – DevOps should constantly monitor the production environment.
  • Change Failure Rate (CFR) – measures the percent of  deployments causing a failure in production, and is calculated by dividing the number of failures by the total number of deployments.
DORA metrics give the engineering leaders truthful insights, as they can analyze the metrics to assess the team performance. Then they can improve their internal processes. By looking at CFR and MTTR, leaders can ensure that their code is robust and stable, while reducing the failures. On the other side, monitoring Deployment frequency and Lead time for changes assures that the team is working at a good pace. Combined, DORA metrics provide crucial info about the team quality and speed of delivery.

What is Deployment Frequency - Definition

As mentioned above - deployment frequency measures the frequency at which code is deployed successfully to a production environment. It is one of the most tracked DORA metrics. In software, deployment frequency is the proxy of the batch size (from LEAN paradigm). Reducing batch sizes reduces cycle times and variability in flow, accelerates feedback, reduces risk and overhead, improves efficiency.

So, deployment frequency basically tracks the size of the batch in production. For example, fewer deployments could mean bigger chunks of changes, while more frequent deployments mean smaller changes. We want more frequent and smaller changes, since it accelerates flow and reduces variability. 

Why is Deployment Frequency Important?

By deploying a small number of changes frequently, the risks associated with the deployment are reduced: smaller changes means less chance of unintended and unwanted consequences. In addition, it allows you to get feedback faster. Smaller issues will flow faster, and will enable higher deployment frequency.

Higher deployment frequency means more changes to the product which brings more value sooner and frequently. It will lead to more feedback and accordingly to better products and more revenue.

How to Calculate Deployment Frequency?

Mathematically, Deployment Frequency = Number of total deployments on an environment in a given period of time. 

For example, if in a month, your team deploys 3 times in the first week, 9 times in the second week, 7 times in the third and 5 times in the final week, then your deployment frequency is six deployments per week. Or, approximately - one deployment per day.

You can also calculate the deployment frequency by setting up your CI/CD tool to notify you when it runs a deployment job successfully, and record this data somewhere. This automatic monitoring and data gathering is less error prone vs a human. For a faster and a more reliable approach to measure the deployment frequency, you can utilize a special tool, such as Axify. These tools do all the work for you - they collect data from your pipeline tool (GitLab CI, Jenkins etc.), keep track of all your successful deployments, and calculate your deployment frequency quickly. 

Deployment Frequency

What is a good Deployment Frequency?

Deployment frequency can differ a lot from team to team and from project to project. Its value also depends on the type of product you're building. Three main contexts relevant for deployment frequency are: SaaS applications, on-premise applications and mobile applications.

  • SaaS applications built on cloud tend to be easier to deploy and deploy more frequently.
  • Mobile applications are subject to the store, so you may limit your deployment frequency.
  • On-premise applications tend to be less frequent deployment (harder to automatically deploy and release management).

According to the DORA State of DevOps Report 2022, high performers do deployments on-demand or multiple times a day, and for others - deployment happens weekly up to once a month.

What causes Low Deployment Frequency?

As stated above - low deployment frequency means to deploy once per month to once in six months. If your deployment frequency is low, you need to uncover the hidden issues in the company. The potential causes of low deployment frequency may be:

  • Complex deployment procedure - if your deployment process is rather complex, it could result in errors and slow down the process, leading to low deployment frequency. When you make large changes to the code, it can cause new bugs and compatibility issues, slowing down the deployment process / deployment frequency.
  • Poor communication and cooperation – usually, if a separate team is responsible for the deployments, hence bottlenecks occur for the other teams, which can slow down the deployment process.
  • Lack of automation - to deploy software regularly – you need to automate the deployment operations, which will speed up your process. Proper automation will help your team ship fewer broken services. If your deployment process is manual - it can cause delays and result in low deployment frequency.
  • Large changes - to handle large changes - it takes time to review and QA the change and it involves more people. It takes more time to approve a change, hence more time to deploy, hence it is less frequent.

How to Improve Deployment Frequency?

Engineering teams tend to be high-performing and deploy at a fast pace. The goal is to deploy more often – in order to deliver more value to your clients. Here are some tips to improve your deployment frequency:

  • Lower the dependency between the teams - each team should have the responsibility to code and deploy its changes. You built it, you run it. You want your team to be autonomous, cross-functional and have no (or very few) dependencies on other teams to make changes. This will reduce delay, and improve overall efficiency (and deployment frequency).
  • Reduce technical debt - technical debt happens when software is developed quickly without spending time to properly maintain and refactor the code. According to CodeScene study - average organizations waste around 25% of their development time due to technical debt. By reducing technical debt, organizations will lower the bugs and other issues in the code, and will make the software development process more efficient, enabling the team to deploy new features and updates more frequently.
  • Reduce the WIP - don't split across multiple projects/features, focus on one change at a time (to optimize value stream, to accelerate flow of issue completion and its deployment). This approach is more efficient, since developers focus on one task at a time. If developers split their day across multiple releases - the team shifts in a bad direction.
  • Automated testing - the goal of automated testing is to quickly confirm that the software application works as expected - without the need for manual intervention. Automated testing tools enable organizations to implement continuous delivery practices. It saves time, reduces the human errors, and enables frequent deployments of software updates, as changes are automatically tested and validated as soon as they are committed to the codebase.
  • Deployment automation - with continuous integration, code is scripted, tests are running and passing, infrastructure changes are specified in code and database migrations can be run with a command line (scripted, or automated).

Relation between Deployment Frequency and Lead Time for Changes

Both of these DORA metrics measure the team speed of delivery. While deployment frequency measures the pace of new code being deployed, lead time for changes measures how long it takes from a commit to production.

Smaller changes = faster flow and less risk.

If an incident occurs, since it is a smaller changer, it is faster to find it and fix it. The lower the Lead time for changes, the more efficient a DevOps team delivers value, which means more efficient automation and good engineering practices. LTFC visualizes how quickly work is delivered to users. Over time, the Lead time for changes should decrease, while your team’s performance should increase. 

Simple way to measure Deployment Frequency

Axify is a single platform to observe all the key performance indicators that will help you improve your development and delivery processes. It is equipped with superior dashboards and provides constant tracking of DORA metrics in real-time, hence simplifying the whole process and empowering teams to concentrate on making improvements.

Axify can track in real time all four DORA metrics:

  • Deployment Frequency - measures how often an organization successfully deploys to production. This important metric makes it easier to test, deploy, provide feedback, and roll back problems, in addition to increasing perceived value for your customers.
  • Lead Time for changes – time it takes from the first commit to successfully executed code in production. This metric allows us to assess the efficiency of software development cycles and initiatives. It tends to lead to organizational, human and technical changes.
  • Change Failure Rate - measures the percent of  deployments causing a failure in production, and is calculated by dividing the number of failures by the total number of deployments.
  • Mean Time to Recover - measures the time needed for the system to recover from an incident in production.

Manual calculations can provide you useful insights, but an automated tool like Axify can prognostically model system behavior and track Deployment Frequency effortlessly. Keeping your eye on the deployment frequency can provide you insights about the overall team pace. By improving the efficiency of your team, you will have a streamlined flow, good developer experience and motivated development team.

To find out more, read our article | Understanding DORA metrics: your complete guide

Software delivery performance

Understanding DORA metrics: your complete guide

Discover the significance of DORA metrics and their role in enhancing software delivery performance. Learn how these metrics can be utilized to gauge and enhance the efficiency of your development teams, fostering more streamlined and effective software development processes.

Software delivery performance

Lead Time for Changes Explained (DORA metric)

Lead time for changes measures how swiftly a modification goes from commit to master and then to production. In feature development, it encompasses sprint, developer work, merge request, review, and integration into the master branch. Minimizing this duration is key for efficiency.

Software delivery performance

Teamwork visibility vs. individual performance: a new way of thinking about productivity

Although it might seem appealing to associate individual activity levels with productivity, such a perspective overlooks the elements crucial for sustained innovation.