Deployment Strategies: Rolling, Blue-Green & Canary

Q: Blue-green vs canary — what's the difference?

Blue-green switches all traffic from the old environment to the new one at once (instant cutover and rollback, but you run two full environments). Canary shifts traffic gradually (1% → 10% → 100%), watching metrics at each step to catch regressions before full exposure.

Deployment Strategies

A deployment strategy is how you move from the running version to the new one without taking down the service or breaking users. The right choice trades off downtime, rollback speed, resource cost, and complexity — and it's one of the biggest levers on release safety.

The unlock most teams underuse is decoupling deploy from release: ship code dark behind a feature flag, then turn it on (and off) independently. That turns a risky "big bang" into a controlled, reversible switch.

TL;DR

Rolling updates are the sensible default (no downtime, gradual).
Blue-green gives instant rollback at the cost of double resources.
Canary is the safest for production — gradual, metric-validated rollout.
Feature flags decouple deploying code from releasing the feature.

Quick Example

A Kubernetes rolling update that never drops below full capacity during the rollout:

Core Concepts

Recreate — stop old, start new; simple but has downtime (fine for dev/test).
Rolling — replace instances gradually; no downtime, brief mixed versions (Kubernetes default).
Blue-green — two identical environments; switch all traffic at once for instant rollback.
Canary — route a small % of traffic to the new version, watch metrics, then ramp up.

Feature Flags

Decouple deploying code from releasing the feature, so you can ship continuously and flip behavior per user/segment:

This makes rollback a config change (turn the flag off), not a redeploy — and enables gradual rollouts and A/B tests.

Best Practices

A pre-release checklist:

✅ Pre-deployment smoke tests pass; database migrations applied (backward-compatible).
✅ Monitoring dashboards ready and a rollback procedure documented.
✅ Automated rollback triggers wired (error rate, latency, failing health checks).
✅ Feature flags configured for risky changes.

Pair deployments with expand/contract database migrations so old and new versions both work during the rollout.

Common Mistakes

No rollback plan

Coupling schema changes to the deploy

FAQ

Which deployment strategy should I use?

Rolling updates as a default — no downtime and low complexity. Blue-green when you need instant rollback and can afford duplicate environments. Canary when you want the safest production rollout and have the monitoring to validate each step. Recreate only for environments where brief downtime is acceptable.

Blue-green vs canary — what's the difference?

Blue-green switches all traffic from the old environment to the new one at once (instant cutover and rollback, but you run two full environments). Canary shifts traffic gradually (1% → 10% → 100%), watching metrics at each step to catch regressions before full exposure.

What are feature flags and why use them?

Flags gate functionality at runtime, so you can deploy code without releasing the feature and turn it on/off per user or segment. They make rollback a config flip instead of a redeploy, and enable gradual rollouts, A/B tests, and kill switches.

How do I roll back safely?

Define automated triggers (error-rate or latency thresholds, failing health checks) that revert to the last good version, keep deployments backward-compatible (especially database changes), and rehearse the rollback so it works under pressure. Blue-green and feature flags make rollback near-instant.