Overview
Blue-green deployment is a release strategy that maintains two identical production environments — “blue” (current) and “green” (new). New code is deployed to the idle environment, tested, and then traffic is switched from blue to green. If problems arise, traffic reverts to the previous environment instantly. This approach eliminates deployment downtime and provides a reliable rollback mechanism. It requires infrastructure capable of running two full environments simultaneously, making it more resource-intensive than in-place deployments but significantly safer for critical systems.
Key Concepts
- Environment parity — Blue and green must be identical in infrastructure, configuration, and data access to ensure reliable switchover.
- Traffic switching — Typically handled at the load balancer or DNS level. Must be atomic to avoid split-brain scenarios.
- Database migrations — The hardest part. Schema changes must be backward-compatible so both versions can coexist during transition.
- Smoke testing — Automated tests run against the green environment before switching traffic.
- Rollback — Switching traffic back to the previous environment. Near-instant compared to redeployment.
- Canary variant — Gradually shifting traffic (1%, 10%, 50%) rather than all-at-once, combining blue-green with progressive delivery.
Trade-offs
- Requires double the infrastructure during deployment (cost)
- Database schema changes must be forward and backward compatible
- Session state and caches may not transfer between environments
- Simpler than canary deployments but less granular in risk management
Related
- Feature Flags provide an alternative for decoupling deploy from release
- CD orchestrates the deployment pipeline
- Kubernetes supports blue-green via service routing and replica sets