Blue-Green & Canary Releases
Deploying without a maintenance window, and separating "shipped" from "switched on".
Deploy Is Not Release
Every strategy below is a way of controlling how many users meet the new version, and how quickly you can undo that. The measure of success is not deployment frequency but how fast you recover when a release is wrong.
Rolling, Blue-Green & Canary
| Strategy | How | Rollback | Cost |
|---|---|---|---|
| Recreate | Stop old, start new | Redeploy old | Downtime |
| Rolling | Replace instances gradually | Roll back gradually | Two versions live at once |
| Blue-green | Full second environment, switch traffic | Switch back — seconds | Double the infrastructure |
| Canary | 1% → 10% → 50% → 100%, watching metrics | Shift traffic back | Needs good metrics and routing |
Blue-green buys the fastest rollback available — the old environment is still running, so reverting is a routing change rather than a deploy. Canary buys the smallest blast radius: a broken release reaches 1% of users, and automation shifts them back before most people notice.
Feature Flags
A flag moves the release decision out of the deployment and into a runtime switch. Code ships dark, gets enabled for staff, then a percentage, then everyone — and is turned off in seconds without a deploy.
| Flag type | Lifetime |
|---|---|
| Release flag | Days — delete once fully rolled out |
| Experiment flag | The length of the experiment |
| Operational kill switch | Permanent, deliberately |
| Permission flag | Permanent — it is entitlement, not a flag |
Automated Rollback
A canary only helps if something is watching. Progressive delivery controllers — Argo Rollouts, Flagger — shift traffic in steps and compare the new version against the old on real metrics, rolling back automatically when it degrades.
| Watch | Because |
|---|---|
| Error rate | The clearest signal something is broken |
| Latency percentiles | Slow is a failure mode users feel |
| Saturation | The new version may simply cost more |
| A key business metric | Checkouts can fall while every technical signal looks fine |
Two practical rules. Give each step long enough to be statistically meaningful — thirty seconds at 1% traffic proves nothing. And make rollback the default response to uncertainty: investigate from a healthy state, not while users are affected.
Interview Questions
What is the difference between deploy and release?
Deploying puts code on servers; releasing exposes it to users. Separating them with flags or traffic control is what makes deployment routine and rollback instant.
Blue-green or canary?
Blue-green gives the fastest rollback — the old environment is still running, so reverting is a routing switch. Canary gives the smallest blast radius, exposing a fraction of users while metrics are compared.
What must be true before any gradual rollout?
Both versions must run against the same database schema, because they run simultaneously. That makes expand-and-contract migrations a prerequisite.
What is the cost of feature flags?
Each one doubles the paths through the code. They need owners and removal dates, or the codebase accumulates hundreds nobody dares delete.
What should an automated canary analysis watch?
Error rate, latency percentiles, saturation, and at least one business metric — checkouts can collapse while every technical signal looks healthy.
What is the right first response to a suspicious release?
Roll back, then investigate from a healthy state. Debugging while users are affected trades their experience for your convenience.