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.
The design of your application can define its success; therefore, as a developer, you need to think about how to organize your CSS to have the greatest impact. The traditional way to organize CSS files in your React app is to import them into each component that is using that…
Why build or buy a robust feature flags as a service platform when you could just implement a simple toggling mechanism as a one-off and be done with it?
Blind spots have a way of coming back to bite you down the road. When building software, the size of that “bite” grows exponentially with time.