Deployment Strategies: Blue-Green, Canary and Rolling
Deployment strategies compared: rolling, blue-green and canary releases, feature flags, database migrations and fast rollback.
Most production incidents start with a change: a deploy, a config update, a database migration. Deployment strategies control how new versions reach users so problems are caught early and rolled back fast. The common strategies are rolling, blue-green and canary releases, often combined with feature flags.
Rolling deployment
Replace instances a few at a time: take one out of the load balancer, upgrade it, health-check it, put it back, move to the next. Kubernetes Deployments do this by default.
- Pros: no extra infrastructure; zero downtime with readiness checks and connection draining.
- Cons: old and new versions serve traffic at the same time for a while; rollback means rolling back again (slow); a bad version reaches everyone by the end.
Blue-green deployment
Run two full environments. Blue serves production; deploy the new version to green, test it, then switch all traffic to green at the load balancer or DNS. Keep blue running for an instant rollback.
- Pros: instant switch and instant rollback; the new version can be tested in a production-identical environment first.
- Cons: double the infrastructure during the release; all users switch at once (no gradual exposure); databases are shared, so schema changes must work for both versions.
Canary release
Send a small slice of traffic (1%, then 5%, 25%, 100%) to the new version and compare its metrics with the old version before going further. If error rates or latency get worse, roll back automatically. Only a small fraction of users ever sees a bad version.
Canaries need good metrics broken down by version and enough traffic for differences to be statistically meaningful. Tools like Argo Rollouts, Flagger and Spinnaker automate the steps and analysis; a service mesh makes percentage-based routing easy.
Feature flags
Feature flags separate deploying code from releasing a feature. Code ships turned off, then the flag enables it for internal users, a percentage of users, or specific customers, and can turn it off instantly without a deploy. Flags also serve as kill switches for graceful degradation. Clean up old flags; long-lived flags become technical debt.
Database changes: expand and contract
During any of these strategies, old and new code run against the same database at the same time, and a rollback brings old code back. Schema changes must therefore be backward compatible:
- Expand: add the new column or table; old code ignores it.
- Deploy code that writes to both old and new structures and reads the old one.
- Backfill existing data into the new structure.
- Deploy code that reads the new structure.
- Contract: once nothing uses the old column, remove it in a later release.
Comparison
| Rolling | Blue-green | Canary | |
|---|---|---|---|
| Extra infrastructure | None | Full second environment | Small |
| Exposure to a bad release | Gradually everyone | Everyone at once | Small percentage |
| Rollback speed | Slow (redeploy) | Instant | Fast (shift traffic back) |
| Needs | Health checks | Traffic switch | Per-version metrics, traffic splitting |
Where it’s used
Release through progressive canaries with automated analysis, rolling back automatically on regressions.
Rolling updates by default; Argo Rollouts and Flagger add canary and blue-green with metric analysis.
Let teams release features to percentages of users and kill them instantly.
Use staged rollouts in app stores plus remote feature flags, since a shipped binary can't be rolled back. See the mobile release flags round.
In an interview
- Mention how changes reach production: canary with automated rollback for risky services.
- Separate deploy from release with feature flags, and keep kill switches for risky features.
- Make schema changes backward compatible with expand and contract.
- Tie rollback triggers to concrete metrics: error rate, latency and business KPIs by version.