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 to make engineering teams more efficient and agile in the software development process. It is very important for the software teams to identify the blockers in the software delivery process and optimize the value stream.

In this article, we elaborate on 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 high-performance development teams from average ones:

• Deployment Frequency (DF) measures the frequency at which code is successfully deployed to a production environment. Engineering teams tend to deliver new features to clients as soon as possible, so this metric is useful for understanding 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 it 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's performance. Then they can improve their internal processes. By looking at CFR and MTTR, leaders can ensure their code is robust and stable while reducing failures. On the other hand, monitoring deployment frequency and lead time for changes ensures that the team is working well. Combined, DORA metrics provide crucial info about the team's quality and speed of delivery.

What is Deployment Frequency - Definition

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

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 they accelerate flow and reduce variability.

Why is Deployment Frequency Important?

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

Higher deployment frequency means more changes to the product, which brings more value sooner and frequently. This will lead to more feedback, which will, in turn, lead 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 your team deploys three times in the first week of a month, nine times in the second week, seven times in the third week, and five 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 than a human. For a faster and more reliable approach to measuring 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.), track all your successful deployments, and quickly calculate your deployment frequency.

What is a good Deployment Frequency?

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

• SaaS applications built on the cloud are 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 deployments (harder to automatically deploy and release management).

According to the DORA State of DevOps Report 2022, high performers deploy 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—if a separate team is responsible for the deployments, 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, speeding 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 them and it involves more people. It takes more time to approve a change, hence more time to deploy, and hence 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 – 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 be responsible for coding and deploying its changes. You built it, you run it. You want your team to be autonomous and 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 it across multiple projects/features; focus on one change at a time (to optimize the value stream, accelerate the flow of issue completion, and deploy it). 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—automated testing aims 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 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's speed of delivery. While deployment frequency measures the pace of new code deployment, 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 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.

A simple way to measure Deployment Frequency

Axify is a single platform for observing 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, 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 testing, deploying, providing feedback, and rolling back problems easier, 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 Recovery - measures the time needed for the system to recover from an incident in production.

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