Release Strategies: Blue-Green, Canary, Feature Flags
Pushing brand-new code to every user at once is risky — if it's broken, everyone is broken at the same moment. So modern teams release gradually and reversibly, using strategies like blue-green deployments, canary releases, and feature flags, and always keeping a way to undo: rollback. The goal is to ship often and sleep at night.
These techniques separate two things people often confuse: deploying code (putting it on the servers) and releasing a feature (turning it on for users). Pulling those apart is what makes safe, gradual rollout possible.
An analogy: a restaurant testing a new dish as a limited daily special for a few tables before adding it to the main menu. If it flops, only a few diners were affected, and it never made the menu.
Blue-Green
A blue-green deployment keeps two identical production environments — call them blue and green. One serves all live traffic while the other sits idle. You deploy the new version to the idle one, check it, then switch all traffic over in an instant. If anything's wrong, you switch straight back. It makes releasing (and un-releasing) nearly instantaneous, with the old version always standing by.
Canary
A canary release rolls the new version out to a small slice of users first — say 5% — while everyone else stays on the old version. You watch that small group closely for errors; if it looks good, you gradually widen to more users, and if it looks bad, you pull it back having affected only a few. The name comes from "canary in a coal mine": a small early warning before the whole rollout.
Feature Flags
A feature flag is a switch in the code that turns a feature on or off without deploying again. You can ship the code "dark" (deployed but switched off), then flip it on for some users, all users, or no one — instantly, no redeploy needed. Flags are what let teams deploy continuously but release features on their own schedule, and turn a misbehaving feature off in a second.
Rollback
Rollback is the always-available undo: if a release goes wrong, you return to the previous known-good version fast. Because you build immutable artifacts (earlier in this chapter), rolling back usually means redeploying the previous artifact — not restoring a backup. A reliable, quick rollback is what makes shipping feel safe: you can always get back to "working" in moments.
The Cadence team ships reminders carefully. They deploy it behind a feature flag (off by default), then turn it on for just 5% of users — a canary. They watch for errors; seeing none, they widen it to everyone. The whole time, the flag is ready to switch reminders off instantly if it misbehaves, and the previous artifact is on hand to roll back to. Gradual, watched, and reversible — shipping without the fear.
- "Deploying and releasing are the same thing." Feature flags separate them: you can deploy code without releasing the feature to users, then flip it on later. That separation is what enables safe gradual rollout.
- "Gradual rollout is overkill for small teams." It's exactly how small teams ship safely — a canary or a flag lets a tiny team release without betting everything on one big switch-over.
- "Rollback means restoring a database backup." It usually means redeploying the previous known-good artifact — fast and clean — not the slow, risky business of restoring data from a backup.
- These strategies are why big sites update constantly without outages — they ship to a few, watch, then widen, with an instant undo ready.
- "Feature flag" and "canary" are core modern vocabulary you'll hear on any team that ships frequently.
- Separating deploy from release reframes shipping as a gradual, controllable dial rather than a single terrifying on-switch.
Knowledge Check
What is a canary release?
- Rolling the new version out to a small slice of users first, then widening
- Switching all of the users over to the new version at the same time
- Keeping two fully identical environments and then switching traffic between them
- A test environment that has no real users on it whatsoever
What does a feature flag let you do?
- Turn a feature on or off without deploying again, releasing on your schedule
- Force every single feature to deploy and release to absolutely everyone simultaneously
- Make the finished program run noticeably faster for all the users
- Automatically write the code for a new feature on its own
How does a blue-green deployment work?
- Two identical environments — deploy to the idle one, then switch traffic over
- Releasing the new version to just a small five-percent slice of users at first
- A switch inside the code that turns one feature on and off for users
- Colouring the app's interface blue, then switching it to green
What does rollback usually mean in practice?
- Redeploying the previous known-good artifact to get back to working fast
- Slowly restoring everything from an old database backup file
- Permanently deleting the new feature so that it can never be tried again at all
- Shutting the entire system down until the problem is fixed by hand
Why do teams separate "deploying" code from "releasing" a feature?
- So code can be on the servers without being turned on for users yet
- Because a strict legal rule requires the two to always be separate
- Because keeping them separate makes the program run much faster
- Because it removes the need to ever test the feature before release
You got correct