Amey-Thakur Blue-green deployments
Two identical production environments, one live: deploy to the idle one, verify it in isolation, then switch traffic in one move. The promise is instant rollback (switch back); the catch is that the database is shared and cannot be duplicated, so schema changes need their own discipline.
Method
- Stand up two full environments behind one switch. Blue serves; green is idle-but-warm; the switch is a load balancer target, DNS weight, or router config (see cloud-networking). Both run the same infrastructure from the same IaC (see infrastructure-as-code): drift between them is where "worked in green, broke in blue" lives.
- Verify green in isolation before the switch. Smoke tests, health checks (see health-checks), and a canary sample of real traffic (or synthetic) against green while blue still serves everyone: the switch happens only on evidence, and its criteria are numeric (see canary-analysis). Green that only got "it deployed" is untested.
- Make the database backward-compatible, always. The shared database must satisfy both versions across the switch and the rollback window: use expand-contract migrations (add columns/tables first, deploy code that writes both, backfill, switch, then contract later: see database-migrations). A migration that breaks the old version turns your instant rollback into a data corruption incident.
- Drain and switch cleanly. Move traffic (all at once, or ramped via weights), let blue drain in-flight requests (see graceful-shutdown), keep blue running untouched for the rollback window. Sticky sessions and in-flight long-running work need a plan: externalize session state so the switch does not log users out.
- Roll back by switching back, within the window. If green misbehaves, flip to blue in seconds: the entire point. This works only while blue is still running the old code AND the database still supports it (step 3); set the window explicitly and hold blue until green is confirmed healthy on real traffic and metrics (see deployment-pipelines, rollback-strategy for the fix-forward-vs-rollback call).
- Automate the whole dance. The deploy pipeline builds green, verifies, switches, and holds blue on a timer, with a one-command rollback (see runbook-writing): manual blue-green is error-prone theater. Track which environment is live somewhere the whole team can see.
Boundaries
- Blue-green doubles environment cost during deploys; rolling deploys or canary (see canary-analysis) achieve zero-downtime at lower cost for stateless services, and are often the better default. Blue-green shines when you want instant whole-system cutover and rollback.
- Stateful services (databases themselves, stateful streams) do not blue-green; their upgrades are careful in-place operations (see kubernetes-workloads StatefulSets).
- The technique manages release risk, not code quality; a bug that passes green's verification ships to everyone at once (unlike canary's gradual exposure).