deployment-strategies

Deployment Strategies

A deployment strategy is really a question of how much information you buy before you're fully committed, and how expensive backing out is if that information is bad. Rolling deploys buy almost nothing (all pods eventually run the new version, fast) but are cheap; canaries buy a lot (real traffic against a small blast radius) at the cost of complexity; blue-green buys instant rollback at the cost of running double infrastructure. Pick based on the blast radius of being wrong, not on what's trendy.

The deploy itself is rarely the risky part — not having a tested way back out is.

Every deployment strategy is a trade between how much you learn before full exposure and how fast and cheaply you can undo it if you learn something bad.

1. Match the strategy to the blast radius, not the org's default

Rolling updates are the right default for most internal services and low-risk changes — Kubernetes does this natively, it's cheap, and a bad version only affects a fraction of traffic briefly before it's caught by a readiness probe. Reach for canary or blue-green when the cost of a bad version reaching real users is high (payment paths, anything customer-facing at scale) or when the change touches something readiness probes can't catch, like subtle data corruption or latency regressions.

• Rolling: default choice; cheap; bounded but not zero exposure during rollout.
• Canary: route a small percentage of real traffic to the new version, watch metrics, expand gradually — buys real-world signal at low blast radius.
• Blue-green: two full environments, instant traffic switch, instant rollback — most expensive to run, fastest to reverse.
• Shadow: mirror real traffic to the new version without serving its responses — buys behavioral signal with zero user-facing risk, but only for read paths.

Done when: the blast radius is written down as a number — users or percent of traffic exposed before the first health gate — and that number is what the rollout actually enforces.