Deploying isn't releasing. Deployment puts code in production; release decides which users see a feature and when. Decoupling the two lets engineering ship continuously while the PM controls exposure.
▸ Try the interactive toolReleasing software is not the same as deploying it, and that distinction is the foundation of this entire tool. Deployment is the technical act of putting code into production. Release is the decision about which users actually see a feature, and when. Modern release strategies decouple the two, so engineering can ship code continuously while the PM controls exposure.
Decoupling deploy from release unlocks a set of powerful techniques: feature flags (code is deployed but hidden behind a toggle), phased rollouts (release to 1%, then 10%, then everyone), canary releases (a small group first, to catch problems early), and A/B tests (different users see different versions). All of them depend on the same insight: once code being in production is separated from a feature being live for users, releasing becomes a controlled, reversible, low-risk decision instead of a single terrifying all-or-nothing event.
Deploy — code is in production (a technical act).
Release — users can see the feature (a product decision).
Decoupling them enables feature flags, phased/canary rollouts, and A/B tests — turning release into a controlled, reversible choice.
When deploy and release are the same event, every launch is an all-or-nothing gamble — and rolling back means a risky redeploy under pressure.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Deploy = release | Every launch is an all-or-nothing event for all users at once. | Decoupling makes release a gradual, controlled decision. |
| Risky rollbacks | Undoing a bad launch means a panicked redeploy. | A feature flag turns rollback into flipping a toggle off. |
| No gradual exposure | A bug hits 100% of users before anyone notices. | Phased and canary releases catch problems at 1% first. |
| Coupled timing | Engineering can't ship until the feature is ready to be fully live. | Decoupling lets code ship continuously, released when the PM chooses. |
Internalise that code reaching production and a feature reaching users are two different decisions. Everything else follows from this. Engineering can deploy whenever; the PM decides release.
Ship code behind a toggle so it's in production but invisible until you choose. This decouples the timeline and makes release — and rollback — a simple switch.
Release to a small percentage first (or a canary group), watch the metrics and errors, then widen. A problem caught at 1% is a minor event; the same problem at 100% is an incident.
Use the gradual rollout to actually watch — errors, performance, key metrics — before widening exposure. The phased approach only protects you if you're looking at each step.
Because release is decoupled, reversing a problematic feature should be flipping the flag off — instant and safe — not an emergency redeploy. Verify this works before you need it.
A team used to couple deploy and release: shipping meant the feature went live for everyone the instant the code hit production. A bug, therefore, meant a bug for 100% of users and a frantic redeploy to undo it — every launch was a held breath.
Adopting feature flags and phased rollout transformed the risk. The next feature was deployed hidden, released first to a small percentage, and watched. A problem surfaced at that small exposure — affecting few users — and was switched off instantly with a flag while it was fixed, rather than becoming a full-blown incident. The same code, the same bug, but a fraction of the blast radius and an instant, safe rollback.
The deliverable is a release approach — flags, phasing, canary, monitoring — that makes exposure a controlled, reversible decision separate from deployment.
| Technique | What it gives you |
|---|---|
| Feature flags | Deploy hidden; release (and roll back) via a toggle |
| Phased rollout | 1% → 10% → 100%, watching at each step |
| Canary release | A small group first, to catch problems early |
| A/B test | Different versions to different users (Module 3) |
The deploy/release distinction turns launching from a single terrifying event into a controlled, reversible dial. It's one of the highest-leverage risk reductions available to a delivery team, and it costs almost nothing once set up.
The deeper shift is psychological as much as technical. When deploy and release are coupled, every launch carries the full weight of all-or-nothing exposure, which makes teams ship less often and more fearfully — the opposite of agility. Decoupling them, via feature flags and phased rollouts, makes each release small, watched, and instantly reversible, which paradoxically lets teams ship more boldly because the downside is capped. A bug caught at 1% with a toggle ready is an inconvenience; the same bug at 100% with a redeploy-only rollback is an incident. The PM's job is to insist on this decoupling, because it converts the riskiest moment in delivery into one of the most controlled.
All-or-nothing launches are high-risk and slow teams down. Decouple with feature flags.
Releasing to 100% at once means a bug hits everyone before you notice. Phase it.
Phasing only protects you if you watch the metrics at each step. Look before widening.
If undoing a release means an emergency redeploy, you haven't truly decoupled. Make it a toggle.
Phased release pairs with the post-launch monitoring discipline (Tool 25) — watch as you widen.
A/B tests (Module 3, Tool 12) are a release technique built on the same deploy/release decoupling.
Decoupling is a powerful mitigation in the risk register (Tool 24).
Controlled release is the delivery-side counterpart to Module 2's phased launch (Tool 23).
Take a risky feature. Describe how you'd deploy it hidden behind a flag, then release it in phases — what percentages, watching what at each step?
Then specify the rollback: if something goes wrong at 10%, exactly how do you reverse it — and how fast?
If your rollback is 'flip the flag off' rather than 'redeploy the old version,' you've genuinely decoupled deploy from release — which is what turns a launch from a gamble into a dial.