This will be a relatively short article. Recently, I participated in discussions about release cadences and how work moves from developers to end-users. These discussions raised many issues for me, one of which was the lack of distinction between a deployment and a release. In this article, I want to clarify that distinction.

Introduction

In the fast-paced world of software development, it's crucial to understand the terms and processes that bring a product to life. Two key concepts that often get confused are "deployment" and "release." While they are closely related, they serve different purposes and happen at different stages in the software delivery lifecycle. Let's break down these terms in a way that's easy to understand.

What is...

A Deployment?

A deployment is the process of moving new or updated code to a specific environment where it can be tested, staged, or run. Think of a deployment as setting the stage for a performance: the props are arranged, the lighting is adjusted, and everything is put in place to ensure the show can go on. However, just because the stage is set doesn't mean the audience (our users) can see the performance yet.

Purpose

A deployment ensures that the code is available, configured, and running correctly in various environments such as development, testing, staging, or production. This process involves several steps, including:

• Setting up the relevant infrastructure,

• Transferring the code to the target environment,

• Configuring the necessary settings and dependencies,

• Verifying that the application is functioning as expected.

Frequency

Deployments can (and should) happen frequently—sometimes multiple times a day. High-performing development teams use Continuous Integration and Continuous Deployment (CI/CD) pipelines to automate and streamline this process, allowing for rapid and reliable deployments.

Visibility

Deployments are typically an internal process first. The code might be running in a production environment, but it's not yet accessible to end-users (using techniques such as feature flags/toggles).

A Release?

A release is when the deployed code becomes available to our end-users. It's like the "opening night" of our performance, where the audience gets to see the show. Releasing software involves more than just making it available; it also includes communicating the new features, providing support, and sometimes training users to ensure they can fully benefit from the updates.

Purpose

The purpose is to deliver new functionality, improvements, or fixes to our users.

Frequency

Releases occur less frequently than deployments. They might follow a regular schedule, such as weekly, bi-weekly, or monthly, depending on our release strategy and operational maturity.

Visibility

Releases are user-facing events. They are announced to our users, who can then start using the new features, improvements, or see the bugs that have been fixed.

Key Takeaways

A deployment is like setting up the stage for a performance. It's an internal process to ensure the code is running correctly in the right environment and is ready for testing and final approval.

A release is the grand opening night where the performance is revealed to the audience. It's a user-facing event where the new features, improvements, or fixes become available to our users.

Benefits of the Distinction

Understanding and maintaining a clear distinction between deployments and releases offers several benefits that can significantly improve the software delivery lifecycle:

1. Increased Stability: By separating deployments from releases, we can deploy code to production environments without immediately exposing it to users. This allows us to monitor the stability of the code in a real-world environment and address any issues before the official release.

2. Reduced Risk: Gradual release strategies, such as canary releases or feature toggles, allow us to introduce changes incrementally. This reduces the risk of widespread issues and makes it easier to fix problematic changes without affecting all users.

3. Enhanced Flexibility: Decoupling deployments from releases provides flexibility in managing feature rollouts. We can deploy features in a dormant state and activate them gradually, allowing for controlled testing and user feedback collection.

4. Optimised Resource Allocation: Product development teams can work on deploying new features, improvements, and fixes continuously, while product and Go to Market (GTM) teams can plan and coordinate releases effectively. This separation of concerns ensures that releases can be well-timed and supported by appropriate communication and resources, while development of new features, improvements, and fixes can continue at full speed.

Conclusion

Understanding the difference between deployment and release helps us manage expectations and ensures we deliver maximum value to our users smoothly and efficiently. By deploying frequently and releasing strategically, we can maintain a strong development process, maximize our efforts, and keep our users happy with continuous improvements.