DevOps Practitioner · Module 6: Safe delivery and release engineering
Rollout Strategies: Rolling, Canary, Blue-Green
Rollout strategy is a decision about how much risk is live at once. Rolling spreads it thin, canary concentrates it where you watch, blue-green keeps the old world warm until the new one proves itself.
10 min reading
Objectives
- Compare rolling, canary and blue-green by blast radius and cost
- Pick the strategy that fits the service size and risk
- Verify the new version with traffic evidence before full cutover
- Roll back through the strategy when verification fails
Why this matters
A full cutover to the new version takes down every user for the same bug, discovered at full scale with no warm fallback. The team knew the old version worked; nothing kept it reachable. Strategy choice is blast radius choice: the same bug costs a fraction of traffic under canary, costs nothing but capacity under blue-green, and costs everyone under flag-day cutover. The bug is inevitable; the radius is a decision made before the release, not during it.
Concepts
Rolling updates (lesson dp09l2) replace instances gradually within one environment: cheap, no extra capacity beyond surge, and the fallback is the recorded previous revision. Canary routes a small share of live traffic (a fixed percentage, a header, a region) to the new version and compares: error rates, latency, business signals against the baseline. Analysis decides promotion or rollback; the L41 lab runs this small and rolls back on failure. Blue-green runs two full environments, switches the router, and keeps green warm until the new blue proves itself over real traffic; the cost is double capacity during the window, the reward is instant return.
Verification is traffic-shaped, never pod-shaped. Running pods prove the process started; serving correct responses under real load proves the release. Each strategy names its verification: rolling watches the new pods' metrics as they take share, canary compares the two versions side by side, blue-green soaks the new side before the switch and keeps the old side until confidence holds.
Pick by risk and wallet. Small internal tools roll; user-facing changes with unknown risk canary; migrations and rewrites with strict recovery needs go blue-green where capacity allows. Mixing is normal: canary the risky service, roll the sidecars. Document the choice per service so the release does not renegotiate strategy under pressure.
Worked example
A demo service releases a faulty version three ways on a small setup. Rolling shows errors spreading with the rollout until rollback; canary shows the small share failing while the majority serves, then rollback drains the canary; blue-green shows the router staying on green after the new side fails verification. Same bug, three radii, quoted traffic evidence for each.
Common wrong move
Calling a full cutover a canary because it happened in two steps minutes apart. A canary that nobody watches with no rollback criteria is a slow flag day. Analysis plus rollback authority is what makes it a canary.
Quick check
An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
Release a faulty demo version under canary on a small setup, show the small share failing while the majority serves, roll back, and quote the traffic evidence.
Pass criteria
The record shows canary share with errors, majority clean, the rollback action, and drained canary with service restored.