Deployment Strategies: Blue-Green, Canary, Rolling

Most outages are self-inflicted by a change

A deploy is a change to a running system, and most outages are self-inflicted by a change. The whole discipline of release engineering is about making that change small, observable, and reversible. Three strategies dominate, and they trade infra cost against rollback speed and blast radius.

Rolling replaces instances in place, a few at a time. You have N pods; the orchestrator (Kubernetes Deployment with maxSurge/maxUnavailable) drains and replaces them in batches until every pod runs the new version. Cost is near zero (no extra fleet), but rollback is slow because "rolling back" is just another rolling deploy in reverse, and during the roll both versions serve live traffic simultaneously. That last fact is the source of most rolling-deploy surprises.

Blue-green stands up a full second environment (green) alongside the live one (blue), warms it, smoke-tests it, then flips the router/load-balancer to send 100% of traffic to green in one move. Rollback is instant: flip the router back to blue, which is still running. The cost is doubling your fleet for the duration, plus the hard part that the shared database must be compatible with both versions at the moment of the flip and the moment of the flip-back.

Canary routes a small slice (1%, then 5%, 25%, 50%, 100%) of real production traffic to the new version and watches it. It has the smallest blast radius of the three because a bad build only touches 1% of users before you catch it. Canary is only as good as its automated analysis: a system (Argo Rollouts + Prometheus, Spinnaker + Kayenta, Flagger) that compares the golden signals (error rate, p99 latency, saturation) of the canary against the baseline over a bake time at each step, and auto-aborts if the canary's SLIs diverge. Without automated analysis a canary is just a slow manual deploy where a human squints at a dashboard.

Rolling:   [v1 v1 v1 v1] -> [v2 v1 v1 v1] -> [v2 v2 v1 v1] -> [v2 v2 v2 v2]   (both versions live mid-roll)
Blue-Green: blue=100% live | green warmed --smoke ok--> router flip --> green=100% (blue idle, instant rollback)
Canary:    v2 gets 1% -> analyze -> 5% -> analyze -> 25% -> ... auto-abort if SLIs diverge

Separate deploy from release

Interview nuance: separate deploy from release. Deploy means the new code is present on machines; release means live traffic is running on it. Blue-green and flags let you deploy without releasing, which is what makes rollback a routing change (seconds) instead of a rebuild (minutes). If your rollback path is "redeploy the old version," you do not have a fast rollback, you have a slow one you have not tested.

The trap that ties this module together is the destructive schema change. During any of these strategies old and new code run at the same time (mid-roll, at the blue-green flip, during a canary). If the new deploy drops or renames a column the old code still reads, the old version breaks the instant the migration runs, and you cannot roll back the code because the schema is already gone. Schema changes must be backward compatible with the currently deployed version, which is the next lesson.

Recap: rolling is cheap but slow to reverse, blue-green buys instant rollback for double the fleet, canary gives the smallest blast radius but needs automated analysis and bake time, and every strategy runs two versions at once so never ship a destructive schema change inside a code deploy.