Deployment Strategies Matrix

Rolling, canary, blue-green. When each.

Rolling deploy

Rolling deploy replaces pods or instances one at a time. The default in Kubernetes Deployments and most ASG configurations. Simple, low cost, well-understood; the right baseline for backwards-compatible changes that do not need atomic cutover.

• One-at-a-time replacement. The default in Kubernetes Deployments; supports zero-downtime for stateless services.
• Limited rollback speed. Rollback rolls in reverse; mid-rollout failures take time to back out.
• Mixed-version window. Both versions serve concurrently during the rollout; backwards-compatibility is required.
• Routine deploys default. Stateless services with backwards-compatible changes; the lowest-cost option for the typical deploy.

Canary deploy

Canary deploy ramps traffic gradually from a small percentage to full. 5%, 25%, 50%, 100%. Each stage gates on health metrics so regressions surface against a slice of users rather than the whole base.

• Gradual percentage ramp. 5%, 25%, 50%, 100%; each stage held long enough for metrics to settle.
• Metric-gated stages. Health, error rate, latency; the ramp only continues if the gates pass.
• First 5% surfaces most issues. The early stages catch the loud regressions; later stages confirm the long tail.
• High-stakes default. Database connection logic, payment paths, ML model swaps; tooling: Argo Rollouts, Flagger, vendor canary support.

Blue-green deploy

Blue-green stands up two full environments. Blue is current production; green is the new version. Traffic flips atomically from blue to green; rollback is instant by flipping back. The cost is double infrastructure during the cutover window, justified for zero-downtime migrations.

• Two parallel environments. Blue is current; green is the new version; the cutover is a routing change, not a rolling replacement.
• Atomic flip. Traffic moves in one switch; no mixed-version window during the cutover.
• Instant rollback. Flip back to blue; both versions stay deployed during the cutover for fast recovery.
• Cost during cutover. Double infrastructure during the window; the trade-off is justified for zero-downtime migrations and high-stakes deploys.

Shadow deploy (dark launch)

Shadow deploy sends a copy of production traffic to the new version without serving its responses to users. Behaviour is observed, users are unaffected, and the new version is exercised against the real shape of production load before it ever serves a customer.

• Mirrored traffic. Production traffic is copied to the shadow; responses are observed but discarded.
• Catches load-shape issues. Real production traffic surfaces problems synthetic load misses.
• Higher operational complexity. Traffic mirroring, separate observability, eventual cutover plan; the cost is justified for risky changes.
• Pairs with canary. Shadow first to validate behaviour, canary second to ramp real traffic; the two-stage flow for the highest-stakes changes.

Picking the right strategy

The right strategy is the lowest-cost option that matches the change. Routine and backwards-compatible: rolling. High-stakes with metric gates: canary. Zero-downtime requirement: blue-green. Risky and hard to test: shadow first, then canary.

• Rolling. Routine, backwards-compatible; the lowest-cost default for most deploys.
• Canary. High-stakes change with metric-driven gates; the production-grade middle ground.
• Blue-green. Zero-downtime requirement, atomic cutover; higher cost, fastest rollback.
• Shadow then canary. Hard-to-test edge cases; observe shadow behaviour, then ramp via canary.