What is Blue-Green Deployment?
Blue-Green deployment is a release management strategy that reduces downtime and risk by running two identical production environments called Blue and Green. While one environment is live and serving production traffic, the other is idle or running the new version for testing.
Zero Downtime
Switch traffic instantly between environments with no service interruption
Instant Rollback
Revert to previous version immediately if issues are detected
Safe Testing
Test new version in production-like environment before routing traffic
Key Concept: At any time, only one of the environments is live, with the environment switch happening instantaneously through service routing changes.
How Blue-Green Deployment Works
Phase 1: Initial State (Blue Active)
Blue Environment: Currently serving production traffic (version v1)
Green Environment: Running new version (v2) but not receiving traffic
Phase 2: After Switch (Green Active)
Blue Environment: Now idle, running previous version (v1) - ready for instant rollback
Green Environment: Now serving production traffic (version v2)
Environment Role Swap
Active → Idle
Idle → Active
After successful deployment and testing, the service routing switches from Blue to Green. The environments effectively swap roles - what was Blue becomes Green (idle) and what was Green becomes Blue (active).
Implementing Blue-Green in Kubernetes
Using Service Selectors
The most common approach is using Kubernetes Service selectors to switch traffic between deployments.
# Service definition - switches by changing selector
apiVersion: v1
kind: Service
metadata:
name: my-app
spec:
selector:
app: my-app
version: v1 # Change this to v2 to switch
ports:
- port: 80
targetPort: 8080# Blue Deployment (v1)
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-blue
spec:
replicas: 3
selector:
matchLabels:
app: my-app
version: v1
template:
metadata:
labels:
app: my-app
version: v1
spec:
containers:
- name: app
image: my-app:v1
ports:
- containerPort: 8080
# Green Deployment (v2)
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-green
spec:
replicas: 3
selector:
matchLabels:
app: my-app
version: v2
template:
metadata:
labels:
app: my-app
version: v2
spec:
containers:
- name: app
image: my-app:v2
ports:
- containerPort: 8080Deployment Process
- Deploy Green Environment
Create the new version deployment alongside the existing Blue environment
- Test Green Environment
Validate the new version using internal endpoints or test traffic
- Update Service Selector
Change the service selector from version=v1 to version=v2
- Monitor Production
Watch metrics and logs for any issues in the new version
- Rollback if Needed
If issues detected, revert service selector back to version=v1
- Cleanup Blue
After stabilization, remove the old Blue deployment
Switching Command
This command instantly switches traffic from Blue (v1) to Green (v2)
Limitations and Considerations
Database Schema Challenges
Blue-Green deployment does not solve the new database schema problem entirely. Both versions must be compatible with the database schema during the transition period.
- Database migrations must be backward compatible
- Consider database versioning strategies
- Use feature flags for database-dependent changes
Resource Overprovisioning
You need to overprovision the cluster size to accommodate running two complete environments simultaneously.
- Requires double the resources during deployment
- Higher infrastructure costs
- May not be feasible for resource-intensive applications
When to Use Blue-Green
- Critical applications requiring zero downtime
- When instant rollback capability is essential
- For applications with stateful components
- When comprehensive pre-production testing is possible
Alternative Strategies
- Canary Deployment: Gradual traffic shift
- Rolling Update: Incremental pod replacement
- A/B Testing: User-based traffic routing
- Feature Flags: Code-level feature control
Blue-Green vs Other Strategies
| Strategy | Risk Level | Rollback Speed | Resource Usage | Best For |
|---|---|---|---|---|
| Blue-Green | Low | Instant | High (2x) | Critical apps, zero downtime requirements |
| Rolling Update | Medium | Slow | Low (+25%) | Most applications, resource efficiency |
| Canary | Very Low | Fast | Medium (+small%) | High-risk changes, user testing |
| Recreate | High | Slow | Normal | Non-critical apps, development |