Last week, I spoke about the foundational idea of decoupling deployment from release. This week, let’s answer the question, “Why would I want to?”
At a high level, there are really just two reasons:
#1: You want to prevent code that’s still a work in progress from being exposed to users before it’s ready.
If you are using Trunk-Based Development, where all code is committed to master no less often than once a day, you need this decoupling or else your work in process will go live the next time a deploy happens.
Even if you aren’t using Trunk-Based Development, you may want to put code on production in a way that only the dev team can execute it.
That leads us to the second reason you would want to decouple deployment from release:
#2: You want to safely test in production, limiting the blast radius if unexpected bad things happen.
Even when you think you are “done” building and testing a feature, there’s still a chance that bad things can happen when that code hits production.
Testing in production may start with just the dev team.
From there, you can proceed through orderly stages of exposure, while checking the health of system and user behavior metrics at each step along the way.
Start small, and learn with less risk
The idea is to start with smaller, low-risk user populations and then to ramp up to larger, higher-risk user populations if things go well or to ramp down to internal users only or just developers doing debugging if things don’t go well.
Don’t roll back or roll forward, just un-release instead
When you decouple deployment from release, you can control the exposure of your code without a rollback or a roll forward. If something goes wrong, there’s no need to re-deploy the prior version or hastily build, test and deploy a patch, since you can simply “un-release” it from any population.
The bottom line is that decoupling deployment from release enables teams to ship more often with greater safety. That, by the way, is why we named this blog and videos, Safe at Any Speed.
Up next: Progressive Delivery
Next time, we’ll start a two-part series on Progressive Delivery, a term that’s been gaining more traction in the last few months. James Governor of Redmonk coined that term after a conversation with Sam Guckenheimer, the Product Owner of Azure DevOps at Microsoft.
What was it Sam said to James?
“Well, when we’re rolling out services. What we do is progressive experimentation because what really matters is the blast radius. How many people will be affected when we roll that service out and what can we learn from them?”https://www.infoq.com/presentations/progressive-delivery/
It’s not just about “turning things off” when things go wrong, but about learning at each stage of the rollout. Being able to turn things off is nice, but without learning, you aren’t really safe, are you? See you next time!
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Great teams don’t run experiments to prove they are right; they run them to answer questions. Guard against wishful thinking and hidden biases with this shortlist of core principles for productive online controlled experiments. (Video, transcript and screenshots from talk given at Pinterest HQ on September 13, 2019)
Last week we walked The Path To Progressive Delivery. This week, we go deeper. What goals can we meet with the Four Shades of Progressive Delivery? After you read or watch this week’s episode, you will be better equipped to choose a Progressive Delivery approach that works for you. My…
Last week I said I would start a two-part series on progressive delivery. Here’s the promised first installment. Whether you’d rather read or watch the video, let’s jump right in! First “Radical” Idea on the Path to Progressive Delivery: Continuous Integration The story starts with the birth of Continuous Integration.…