Blue-Green Deployment: A Complete Beginner-to-Advanced Guide

Table of Contents

1. Introduction to Blue-Green Deployment
2. Core Concepts
3. Benefits and Drawbacks
4. Step-by-Step Implementation Guides
   • AWS (Elastic Beanstalk / ECS / ALB)
   • Kubernetes (Services, Ingress, Istio)
   • Azure DevOps
   • Jenkins Pipelines
   • Terraform / Helm / Ansible
5. Sample Code Snippets & YAMLs
6. Architecture Diagrams
7. Real-World Use Cases & Scenarios
8. Testing & Verification
9. Risks and Mitigation
10. Best Practices and Patterns
11. Sample Project Repository
12. Glossary
13. FAQs
14. Quizzes

---

Introduction to Blue-Green Deployment

Definition: Blue-Green Deployment is a release management strategy that minimizes downtime and risk by maintaining two identical environments: one (Blue) for the current live version, and the other (Green) for the new version.

Purpose:

• To provide zero-downtime deployments
• Enable safe rollbacks

How it Works:

• Deploy new version to the Green environment
• Run tests
• Switch traffic from Blue to Green via a load balancer or DNS change

Comparison with Other Strategies:

Strategy	Downtime	Rollback	Complexity	Use Case
Blue-Green	None	Easy	Medium	Full app upgrade
Canary	Low	Controlled	High	Gradual rollout
Rolling Update	Low	Medium	Low	Stateless microservices

---

Core Concepts

🔹 Active/Passive Environment

• Only one environment is live at a time (active).
• The passive environment is used for deployment and testing.

🔄 Traffic Switching

• DNS-based (e.g., Route53)
• Load Balancer (e.g., AWS ALB, NGINX)
• API Gateway (e.g., Istio VirtualService)

🧯 Rollback and Failover Strategy

• If an issue occurs, simply reroute traffic back to the previous (Blue) environment.

---

Benefits and Drawbacks

✅ Benefits

• Zero Downtime
• Instant Rollbacks
• Improved Testing Before Production

❌ Drawbacks

• Duplicate Infrastructure Cost
• Environment Drift (Blue and Green can go out of sync)
• Complex Load Balancer Configurations

---

Step-by-Step Implementation Guides

🔸 AWS (Elastic Beanstalk / ECS / ALB)

1. Create two environments in Elastic Beanstalk (Blue & Green)
2. Deploy new version to Green
3. Use ALB listener rules or Route53 switch to route traffic to Green
4. Validate and delete or keep Blue

🔸 Kubernetes (Services, Ingress, Istio)

apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    version: green

• Use labels (version: blue/green)
• Switch service selector or use Istio’s traffic splitting

🔸 Azure DevOps

• Create release pipelines for Blue and Green stages
• Use Azure Traffic Manager or App Gateway to switch endpoints

🔸 Jenkins Pipelines

deployBlueGreen(env) {
    stage("Deploy to Green") { ... }
    stage("Switch Traffic") { ... }
    stage("Verify") { ... }
}

🔸 Terraform / Helm / Ansible

• Use terraform apply with separate environment variables
• Helm upgrade with --set image.tag=green
• Ansible playbooks to switch routing configurations

---

Sample Code Snippets & YAMLs

Kubernetes Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green

NGINX Load Balancer

upstream myapp {
  server blue.example.com;
  # server green.example.com; # uncomment to switch
}

---

Architecture Diagrams

Blue-Green Flow

[Developer] → [CI/CD Pipeline] → [Green Env]
                                 ↓
                        [Load Balancer]
                            ↓     ↑
                        [Blue]   [Green]

DNS-Based Switch

[User] → [DNS (Route53)] → [Blue | Green IP]

Multi-Region

[Global Traffic Manager]
     ↓            ↓
[Region A]     [Region B]
  Blue/Green    Blue/Green

---

Real-World Use Cases & Scenarios

Application Upgrade

• Deploy new version in Green
• Test → Switch → Remove Blue

A/B Testing

• Blue and Green host different versions/features
• Route % traffic accordingly

Disaster Recovery

• Blue and Green can exist in different regions for DR

---

Testing & Verification

Smoke Testing

• Perform API checks, database health checks before traffic switch

Monitoring & Logging

• Use tools like Prometheus, Datadog, CloudWatch

Health Checks

• Define in load balancer or Kubernetes liveness/readiness probes

---

Risks and Mitigation

Traffic Leakage

Mitigation: Strict routing rules; kill old service completely

Configuration Drift

Mitigation: Use Infrastructure-as-Code

Deployment Lag

Mitigation: Synchronize pipelines; validate artifact versions

---

Best Practices and Patterns

• Use Feature Toggles for testing in production
• Implement GitOps for declarative rollouts
• Set up Auto Rollback on failed health checks
• Always keep Monitoring and Alerts enabled

---

Sample Project Repository

• GitHub (Mock): Blue-Green K8s Sample
• GitHub (Mock): AWS ALB Switcher Script

---

Glossary

• Blue Environment: Currently live environment
• Green Environment: Staging/testing environment
• DNS Switching: Changing DNS records to reroute traffic
• GitOps: Using Git as the single source of truth for deployments

---

FAQs

Q1. Can I implement blue-green on monoliths?

Yes, but it’s more cost-intensive.

Q2. Do I need Kubernetes for blue-green?

No. Any infra supporting routing rules can be used.

Q3. Is blue-green better than canary?

Depends on the risk tolerance and system complexity.

---

Quizzes

1. Which environment receives traffic during deployment?

• Green
• Blue

2. What’s a major benefit of Blue-Green?

• Zero downtime
• Faster rollbacks

3. Which tool is not used for traffic routing?

• NGINX
• Istio
• Redis

---

End of Guide – Happy Deploying!