Why does deployment frequency matter?

Early feedback is an important stage of software engineering. When we release our code to production in small batches sizes early and often, we get valuable feedback from our customers which guides our product in the right direction. That’s why deployment frequency is a key DORA metric for qualifying software delivery performance.

This article will take a deep dive into that metric. We’ll go over why it matters and what strategies you can take to start releasing multiple times a day, making you a high-performing software organization.

What is deployment frequency?

Deployment frequency is a metric that is used to measure how often an engineering team is deploying their code to a production environment. 

High-performing engineering organizations deploy to production multiple times a day. That said, many companies can take as long as a week or sometimes months to get their code out the door.

Why does deployment frequency matter?

In software engineering, feedback is essential. Without it, you’re only making guesses about what works.

Throughout the entire software delivery process, numerous stages involve early and fast feedback to drive incremental change. A good developer typically employs a test-driven development (TDD) approach for early feedback. 

This involves writing tests first, then the application logic, which encourages developers to continuously test and rewrite their code continually until the tests pass. 

You can see this early feedback strategy in continuous integration (CI) pipelines as well, where testing pyramids will run smaller, faster tests first and run longer, larger tests last.

Both TDD and CI pipelines encourage developers to catch faulty code earlier in the process rather than the end.

Early feedback is a natural fit for production deployments to guide feature development and protect the stability of the product. 

Releasing small changes can allow customers to provide feedback and help us decide whether you’re on the right track, which will inform future decision-making about functionality. 

If you release a small batch of faulty code, it’s a lot easier to revert that quickly than a release that contains a week’s worth of changes. 

Having a higher deployment frequency gives your organization the ability to be more nimble in making changes. 

How should you approach increasing deployment frequency?

Metrics like deployment frequency are not the full picture. They are merely indicators of the state of the engineering process. It’s possible to game the metric of deployment frequency in a variety of ways:

• Releasing small, insignificant changes
• Releasing poorly tested changes
• Not reviewing code results in lower code quality

Increased deployment frequency should come from great engineering practices, not metric manipulation. There is a necessary mixture of technical and cultural components that will lead to a natural increase in deployment frequency: having automation in place, reducing the size of a change, and enabling developer ownership of the release process.

Having a robust CI/CD pipeline

High-performers in the deployment frequency category for DORA metrics consistently have a robust CI/CD system.

To deploy multiple times a day, you need an automated build pipeline to reduce the overhead and toil of releasing software to customers. The last thing you want is a convoluted, manual process for building, testing, and deploying your code. It’s a surefire way to make sure you release to your customers less frequently. Having a CI/CD pipeline in place instills confidence when making changes. That confidence leads to more frequent changes.

Minimizing the size of changes

A robust CI/CD system paves the way for getting code built and out the door faster, but it takes time for engineering departments to adapt and leverage this capability. If your engineers tend to work on large pull requests that lead to lots of changes in a single Git commit, it’s going to be hard to deploy frequently, even if you have the tools.

Technical leadership should lead by example and encourage their engineering department to push smaller batch sizes. This has multiple benefits for the organization:

• Simplified code review:  With large pull requests, it’s easy for code reviewers to get overwhelmed by the sheer amount of change; smaller requests are easier to process.
• Faster reversion: . With smaller changes, you can narrow down the culprit for the bug much faster. This reduces downtime and focuses daily workloads.
• Supports code quality: A smaller footprint leads to more focus on providing maintainable, well-tested code. Documentation tasks are more manageable in smaller chunks.

Building an ownership culture

To tie it all together, the entire organization needs to have the right culture built in to accelerate deployment frequency and release value.

From product managers to developers, QA teams to DevOps teams, you can observe where there might be bottlenecks in our process that prevent us from shipping code quickly. 

For example, do you follow a traditional release process or do developers have a bit more autonomy over the process using feature flags? Are developers waiting for QA teams to test or for infrastructure to be ready from DevOps teams?

If this is the case, there’s probably some opportunity to shift left to enable developers to be more involved with that process.

Summary

Deployment frequency isn’t a silver bullet. Just because you can deploy multiple times a day doesn’t mean you’re providing value.

However, building an automation and ownership culture to support on-demand deployments is the right step to building an organization equipped to change and learn from its failures.

Deployment frequency is an excellent metric to track and strive for improvement as it encourages establishing key underlying components of a strong engineering organization.