Blue-Green Deployment

Blue-green deployment is a release strategy built on a simple trick: keep two identical production environments and only ever release to the one nobody is using.

How it works

1. Blue is live and serves all user traffic.
2. Green sits idle and receives the new version, patches or configuration.
3. You test Green in isolation (smoke tests, QA, performance checks) while users stay on Blue.
4. Cut over: a load balancer, reverse proxy or router switches traffic from Blue to Green in one step.
5. Roll back: if anything goes wrong, switch traffic straight back to Blue.

Trade-offs

Good: near-zero downtime, instant and low-risk rollbacks, and testing in a genuinely production-like environment before users see the change.

Costly: you run two full stacks, so infrastructure roughly doubles. The hard part is the database: schema changes have to work for both versions at once, backward and forward compatible, or the “instant rollback” isn’t instant.

The bonus most people miss

Martin Fowler points out that it’s the same mechanism you need for a hot standby, so every release doubles as a test of your disaster-recovery procedure. As he puts it, “I hope that you release more frequently than you have a disaster.” That makes it a direct lever on recovery time (SLA vs SLO vs SLI) and on how fast you recover from a failed change (DORA Metrics).

Where it fits

It’s one of the release safety nets that visual low-code tools usually lack (Low-Code Platforms: Where Do They Belong?), and one of several ways to release in slices alongside feature flags (Growing a Platform: Breadth, Depth and Gear Shifting).

Sources: Martin Fowler, BlueGreenDeployment · AWS, Blue/Green Deployments whitepaper