Recently, there was a very active twitter thread that started when John Cutler asked whether everyone knew about the idea of decoupling deploy and release:
Let’s take three minutes to clear this up because being able to decouple deploy from release is an essential foundation to practicing modern software delivery.
Feel free to watch, read or do both!
First, let’s offer up a straightforward definition of the two terms in the context of “decouple deploy from release”
- Deploy is pushing your code to some part of your infrastructure.
- Release is exposing code to execution, or, put more simply, “turning it on.”
What a Lovely Decouple, and Worth Watching Closely, Too!
When you decouple deploy from release, you can push code to anywhere, even production, without impacting users or your business.
You then can then choose to release it gradually and/or selectively to support internal testing, dogfooding by employees, and progressive rollouts that expose the code to ever-larger numbers of users.
Importantly, if you set things up right, you can also compare the health of system metrics and user behavior between the populations exposed to the new code and those not yet exposed to it.
Release: a Noun or a Verb?
It’s not surprising that there’s a bit of confusion over this idea of decoupling deploy from release.
Historically, we’ve used the term release to represent the bundle of code that is packaged for delivery. The release was then deployed to some infrastructure somewhere.
Bottom line, “release” was used mostly as a noun, as in, “We are building a release” or “We are deploying a release.” When you deployed a release, you were taking it live.
Releasing a Little at a Time
With the advent of continuous deployment pipelines and progressive delivery, we needed to flip the terms around, using “release” as a verb, as in “We’ve released it to internal users only.” Feature flags make that possible by dynamically controlling the extent of exposure, dialing it up or down on a moment’s notice.
Call It What You Want, It’s The Pattern That Matters
It’s possible that new ways to describe this pattern will come along. One suggested solution is to use verbs such as “ramp” that maintain release’s noun-like focus, so you can say, “We have ramped the release to 10% of users.”
In the meantime, the important thing is to learn about the underlying pattern, because it’s an essential foundation for modern software delivery:
This is about decoupling the movement of code around your infrastructure from the exposure of that code to users.
Catch The Decoupled Release Train
Whether you use “release” as a noun or a verb, being able to control (and learn from!) the gradual exposure of code, rather than the high stress of betting your business on “big bang” cutovers, delivers many benefits! We’ll talk more about that in future episodes of Safe at Any Speed.
Jump to the next episode of Safe at Any Speed: Why would I want to decouple deployment from release?
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
At Split, we “dogfood” our own product in so many ways. Our engineering and product teams are using Split nearly every day. It’s how we make Split better.
A/B testing is a powerful tool for learning about your users, understanding your features’ impact, and making informed business decisions. To ensure you make the best decisions and are extracting the most insights from your experiments, some experimental design guidelines are essential. These guidelines can be cumbersome or confusing at…
Feature flags provide so much for software organizations: they allow teams to separate code deployment from feature release, test in production, run experiments, and more. However, some rules apply to the feature flagging process that are easy for teams to overlook. I’ve gathered the best practices of feature flags from…