Blue/green deployment
What it is
Blue/green deployment is a release pattern that maintains two identical production environments — blue (current) and green (new) — and switches user traffic between them in a single, near-instantaneous cutover. You deploy the new version to green, validate it, then redirect the router/load balancer from blue to green atomically. Blue stays ready as the instant fallback.
Why it exists
By keeping the previous environment warm, you get zero-downtime releases and a trivial, atomic rollback: if green fails, point traffic back at blue. This eliminates the in-place-upgrade window where old and new code coexist on the same instances.
Key ideas
- Two full environments (compute, config, DB migrations considered) — green is fully prepared before any traffic moves.
- Atomic switch: a load balancer / router / deployment slot swap redirects traffic — instant, no per-instance draining.
- Rollback = switch back — flip the router to the previous environment rather than redeploying.
- On Azure, App Service deployment slots are a common blue/green implementation (swap slots).
- Cost/consistency note: you run two environments (doubled capacity), and stateful components (databases) must be handled carefully so both colors share compatible state.
How it fits
Blue/green is a deployment pattern selected by the release strategy. It prioritizes instant switch + instant rollback over gradual exposure.
Exam notes
- Blue/green = two environments + atomic traffic switch; gives zero downtime and instant rollback.
- Choose blue/green when you need a clean cutover with immediate fallback (e.g. slot swap on App Service).
- Contrast with canary (gradual %) and rings (cohort-based) which give progressive exposure rather than an all-at-once switch.
Related
release-strategy · deployment-slots · rollback-strategy · canary-deployment · release-definition
📘 Source: Microsoft Learn — Blue Green Deployment