In software delivery, it’s common to use the terms release and deployment to refer to the same thing: making software available to users. The terms are traditionally synonyms because they happen at the same time. However, modern software delivery practices encourage us to separate the concepts.
Let’s define the terms with more precise language and look at the practical benefits of the distinction:
- Deployment is when you install a software version on an environment
- Release is when you make software available to a user
You could use the word release to describe a package ready for use outside the development team. However, by referring to this as a software version, you can avoid getting into a situation where you release (verb) a release (noun). Instead, you deploy or release a software version.
Technical and business tension
When DevOps was created, it recognized a natural tension between development and operations. The development team wanted to deploy more often to get new features out, while the operations team wanted to deploy less often to keep the system stable. The goal of DevOps was to resolve this tension.
If your releases are linked to deployments, you’ll find a similar tension between development and the business. You might have had a situation where the development team wanted to deploy a software version, but the business wanted to hold back the launch for marketing activities or a trade show.
By decoupling releases from deployments, developers can deploy to production frequently and the business can decide when to launch specific features.
A timeline for change
There’s a 4 step timeline for decoupling releases from deployments in your organization:
- Adopt the precise terms
- Introduce the architecture
- Start deploying and releasing independently
- Transfer control
Let’s look at what those steps mean.
Adopt the terms
The language change is the easiest place to start. By increasing your precision when talking about deployments and releases, you can start thinking differently about the two different actions.
You also need to bring your business stakeholders along on this linguistic journey. Having a shared language between the business and technical team members reduces the amount of explanation needed when talking about the software and its deployment pipeline.
While you coach your organization in semantics, you can start the next step.
Introduce the architecture
There’s a high risk of introducing release controls that become hard to manage. Without a careful design, you could end up with conditional statements scattered through your system or with several competing release control toolsets.
That’s why your release control toolset is an architectural decision.
Most release control is done with feature toggles or feature flags.
- A feature toggle is a simple on or off switch for a feature
- A feature flag allows selection between different versions of a feature
You can reduce complexity by limiting how many feature controls you have and the states each control has. You should remove release controls by default once the feature’s available to all users. You can identify these regularly and remove them in the next deployment.
In some cases, you may decide to implement a long-lived release control. For example, a toggle that lets you temporarily remove a resource-heavy feature during a production incident.
Release controls can apply to all users or groups of users. You should limit the number of groups and the release controls you apply to these groups at one time. You can use group-based release controls for a canary release (where you test out a feature with a small group of early-access users) or for A/B testing two different feature implementations.
There’s helpful guidance on limiting complexity in this article on feature toggles by Pete Hodgson on Martin Fowler’s website.
Your design for release controls should include a level of audit logging. Audit logging has high value when you respond to bug reports or production incidents.
When you test your software, you should use realistic business configurations rather than trying to test every combination of release controls.
Release independently
With a release control in place, you can deploy more often with the feature switched off. You can then wait for the business to line up their launch activities and release the feature when they’re ready without needing a deployment.
You should find the introduction of the release control has resolved the tension between development and the business. However, the business still depends on an engineer to throw the switch. You can take this a step further in the final step.
Transfer control
You might decide to keep hold of the release controls while you gain confidence that everything works smoothly. In the longer term, you should make the appropriate controls available to authorized business users.
When doing this, ensure they only have release controls intended for business use. You don’t want to trigger a critical incident only to find someone accidentally switched off one of your resource-heavy features.
You should already have an audit log of release control changes. The audit log is even more vital as you extend the group of users who can make changes.
Summary
You can resolve classic developer and business tensions by separating releases and deployments. You can create a release control toolset that makes it possible to release features at runtime. You must design release control to limit the complexity and prevent conditional statements from appearing all over your code.
By gradually introducing the concept of independent releases, you can take the business people with you on the journey. They should be able to launch a feature at the push of a button, just like the development team should be able to deploy on demand.
Further reading
- You can find more definitions in our DevOps glossary
Help us continuously improve
Please let us know if you have any feedback about this page.
