Blue-Green Deployment | Glossaire

Blue-Green Deployment is a release management technique that maintains two identical, interchangeable production environments. One environment (Blue) hosts the currently running production version, while the other (Green) receives the new version. The switch occurs at the router or load balancer level, enabling near-instantaneous rollback if issues arise.

Fundamentals of Blue-Green Deployment

Two strictly identical production environments (infrastructure, configuration, capacity)
Instant traffic switching via DNS routing, load balancer, or reverse proxy modification
Immediate rollback capability by redirecting traffic to the previous environment
Complete validation of the new version under real conditions before user exposure

Key Benefits

Zero downtime during deployments, ensuring service continuity
Near-instant rollback (seconds) when anomalies are detected
Real production validation without user impact through smoke testing
Drastically reduced operational risk compared to in-place deployments
Ability to test load and performance under conditions identical to production

Practical Example with Kubernetes

blue-green-service.yaml

# Service pointing to the active version
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
    version: blue  # Switch to 'green' to deploy
  ports:
  - port: 80
    targetPort: 8080
---
# Blue Deployment (current version)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: blue
  template:
    metadata:
      labels:
        app: my-app
        version: blue
    spec:
      containers:
      - name: app
        image: my-app:v1.2.0
---
# Green Deployment (new version)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: green
  template:
    metadata:
      labels:
        app: my-app
        version: green
    spec:
      containers:
      - name: app
        image: my-app:v1.3.0

Step-by-Step Implementation

Provision two identical environments with sufficient capacity to handle 100% of traffic
Deploy the current version to the Blue environment and route all production traffic to it
Deploy the new version to the Green environment in parallel without affecting production
Execute validation tests (smoke tests, health checks, load tests) on Green
Progressively switch traffic to Green (optional: start with a subset of users)
Intensively monitor key metrics (errors, latency, performance) for 15-30 minutes
Keep Blue on standby during the stabilization period (typically 24-48h)
Upon success, deactivate Blue and prepare it for the next deployment

Pro Tip: Database Management

The main complexity of Blue-Green involves database schemas. Use backward-compatible migrations (adding optional columns, no deletions) and deploy schema changes independently, before application code. Consider the expand-contract approach for major structural modifications.

Associated Tools and Technologies

Kubernetes with Istio or Linkerd for advanced traffic splitting
AWS Elastic Load Balancer with Target Groups for environment switching
CloudFlare or Route 53 for DNS switching with short TTL
Spinnaker for automated multi-cloud deployment orchestration
Argo Rollouts for progressive GitOps deployment strategies
Terraform or Pulumi to provision identical environments via IaC

Constraints to Anticipate

Blue-Green doubles infrastructure requirements during deployment, which can represent significant cost. For cloud environments, optimize with auto-scaling and quickly deprovision the inactive environment. This strategy is not suitable for systems with complex state or tightly coupled databases without appropriate migration strategies.

Blue-Green Deployment represents a strategic investment for organizations targeting high availability and operational risk reduction. While requiring temporarily doubled infrastructure, this approach virtually eliminates service interruptions and provides unmatched rollback assurance. For mature DevOps teams, it often serves as the stepping stone before adopting more sophisticated strategies like canary deployment or feature flagging.