Why does deployment frequency matter?

Delivering high quality software is a lot like delivering high quality baked goods.

Hear me out.

When you watch a baking show, you’ll notice that competitors will sometimes bake a small portion of their recipe early on; they don’t put their whole mixture in the oven at once. Why?

These bakers – much like effective software engineering organizations – understand the importance of early feedback to drive results. 

That initial bake can tell them whether they need more or less of an ingredient, or whether the whole product missed the mark!

The same holds true for software engineering: When we release our code to production in small batches sizes early and often, we get valuable feedback from our customers which can guide our product in the right direction. 

It’s no wonder that deployment frequency is a key DORA metric for qualifying software delivery performance.

This article will take a deeper dive into that metric. We’ll go over why it matters and what strategies you can take to start releasing multiple times a day to reach that elite status of 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 should aim to deploy to production multiple times a day. That said, the reality is 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 really only making best guesses about what works.

Throughout the entire software delivery process, there are numerous examples that utilize 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 the developer to continuously test and rewrite their code until the tests pass. 

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

Both of these approaches encourage developers to catch faulty code earlier in the process rather than the end.

It makes sense that this strategy would be employed to 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. 

In essence, having a higher deployment frequency gives your organization the ability to be more nimble in making changes. 

 

These high performers can easily release small features and provide quick fixes, making them more reactive to their customers and having an edge on the competition.

How should you approach increasing deployment frequency?

One thing to keep in mind is that a metric like deployment frequency is not meant to be the end result. It’s merely an indicator that the engineering organization is doing the right thing. 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 resulting in lower code quality

This is not the intention of this metric. Instead, a higher deployment frequency comes as a result of great engineering practices underneath.

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 change, and developer ownership in the release process.

Having a robust CI/CD pipeline

One attribute commonly associated with high-performers in the deployment frequency category for DORA metrics is they have a robust CI/CD system in place.

To deploy multiple times a day, you need to have an automated build pipeline to reduce the overhead and toil of releasing software to customers. 

The last thing you want is having a convoluted, manual process to building, testing, and deploying your code. It’s a surefire way to make sure you release to your customers less frequently.

Having this pipeline in place instills the feeling of confidence when making changes. And 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 have a tendency 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. 

There are also a lot of hidden negatives with this type of approach.

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

• It’s easier for developers to review code. With large pull requests, it’s easy for code reviewers to get overwhelmed by the sheer amount of change; smaller requests narrow that focus
• Reverting bad code is simpler. WIth smaller changes, you can narrow down the culprit for the bug much faster than larger changes
• Emphasizes code quality. A smaller footprint leads to better focus on providing maintainable, well-tested code

Building an ownership culture

To tie it all together, the entire organization needs to have the right culture built in to increase deployment frequency and deliver value to customers faster.

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 with the use of feature flags? Are developers waiting for QA teams to test or waiting 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 is not a silver bullet. Just because you can deploy multiple times a day doesn’t mean you’re providing value to your customer.

However, building up the automation and the culture to support on-demand deployments is the right step to building an organization that is 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.