Deployment Strategies · DevOps & CI/CD Deep Dive

The Four Patterns

Side-By-Side

Strategy	How it works	Rollback time	Cost
Rolling	Replace old instances with new ones, a few at a time.	Slow (re-roll old)	Cheap — no extra capacity needed.
Blue / Green	Spin up a full copy (green), test, flip the load balancer.	Instant — flip back to blue.	2× capacity during cutover.
Canary	Send 1–5% of traffic to new version; expand if golden signals stay healthy.	Fast — pull traffic back.	Modest — extra capacity for the canary tier.
Feature flag	Ship code dark; toggle the new path on for a cohort.	Instant — flip the flag.	Cheap, but adds dead-code paths and observability burden.

When to Pick Which

Routine, backwards-compatible release → rolling. K8s Deployment does this by default.
Schema or contract change you can't gradually roll back → blue/green, with the old env held for some bake time.
High-traffic service, real risk of regression → canary, gated on SLO metrics. Argo Rollouts and Flagger automate this on K8s.
Risky logic change, not a deploy risk → feature flag (LaunchDarkly, Statsig, Unleash, OpenFeature). Decouple "deploy" from "release."
Mobile → staged rollout in App Store / Play Console + remote config.

Hidden Pitfalls

Schema migrations don't blue/green. Make schema changes additive: add columns first, dual-write, drop later — over multiple deploys.
Sticky sessions break canary — users who land on v2 may need to stay there. Header- or cohort-based routing.
Cache poisoning — long TTL caches can serve old responses long after rollback.
Feature-flag sprawl — every new flag is forever debt. Track expiry; clean up.
Observability is the floor. Without SLO-driven dashboards and alerts, "canary success" is just guessing.
Auto-rollback on errors matters more than fancy strategy — define your guardrails (error rate, p99 latency) and wire them.

Continue