# Rolling, blue-green and canary deploys

> Three ways to replace running code, and how each limits how many users a bad release reaches.

Concept · Running systems · https://levelcode.org/concepts/deployment-strategies

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](https://levelcode.org/concepts/liveness-readiness). Old Pods need [graceful shutdown](https://levelcode.org/concepts/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](https://levelcode.org/concepts/expand-contract-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](https://levelcode.org/roadmaps/devsecops/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](https://levelcode.org/concepts/trunk-based-development) 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.