Concept · Running systems
Rolling, blue-green and canary deploys
Three ways to replace running code, and how each limits how many users a bad release reaches.
Every deploy is a risk. Deployment strategies don't make releases less buggy. They control how many users a bad release reaches and how fast you can undo it.
| Strategy | How | Rollback | Extra capacity | Exposure to a bad release |
|---|---|---|---|---|
| Recreate | Stop all old, start all new | Redeploy old | None | Everyone, plus downtime |
| Rolling | Replace instances a few at a time | Roll forward or back gradually | A little (maxSurge) | Grows as the rollout proceeds |
| Blue-green | Start a full new copy (green), switch traffic at once | Switch back, which is instant | 2× during the switch | Everyone, but briefly |
| Canary | Send 1% → 5% → 25% → 100% to the new version, checking metrics at each step | Send 0% to it | Small | Only the canary slice |
Rolling
The Kubernetes Deployment default. maxUnavailable and maxSurge control the pace, and new Pods only receive traffic once they pass readiness. Old Pods need graceful shutdown or requests drop on every step.
For a while both versions serve traffic at once. APIs, message formats and the database schema have to work with both: see zero-downtime migrations.
Blue-green
Run the new version at full size next to the old one, test it in place, then flip the router, DNS name or load balancer target. Rollback is just flipping back, which suits releases you want to switch over atomically. The costs are double capacity during the switch, and the question of what happens to sessions, caches and in-flight work when you flip.
Canary
Route a small share of traffic to the new version, compare its error rate and latency with the old version's, and move forward only if they're healthy. Tools like Argo Rollouts and Flagger, usually with a service mesh or gateway for weighted routing, automate the analysis and the rollback.
- Compare against the baseline running at the same time, not against yesterday. Traffic patterns change during the day.
- Make sure the canary gets enough traffic to be statistically meaningful. One percent of a small service may be a handful of requests.
- Route consistently. Keep each user on one version, so a user doesn't bounce between versions request by request.
Separate deploy from release
Feature flags let you deploy code turned off and enable it for users separately, even per customer. Then turning off a bad feature takes seconds, not a redeploy. Combine strategies: canary the binary, then roll out the feature behind a flag.