Blue-Green Deployment

Overview

Blue-Green Deployment runs two identical production environments (Blue and Green) simultaneously. Traffic serves from one (say Blue, the current version). When deploying, the new version is deployed to Green, validated, and then traffic is switched to Green atomically. Blue becomes the standby and provides instant rollback: just switch traffic back.

Origin

Blue-Green Deployment was popularised by Dan North and Jez Humble. It appears in "Continuous Delivery" (Humble and Farley, 2010) as a key pattern for zero-downtime releases. Cloud infrastructure made it practical by removing the hardware constraint of running two environments.

Examples

# Simplified AWS SDK calls demonstrating blue-green switch
require 'aws-sdk-elasticloadbalancingv2'

alb = Aws::ElasticLoadBalancingV2::Client.new

# Get the listener and its current rules
listener_arn = 'arn:aws:elasticloadbalancing:...'

# Blue target group (current production) gets 100% traffic
# Green target group (new version) gets 0% traffic during validation

# After green is validated, atomic switch:
alb.modify_rule(
  rule_arn: forward_rule_arn,
  actions: [{
    type: 'forward',
    forward_config: {
      target_groups: [
        { target_group_arn: green_tg_arn, weight: 100 },
        { target_group_arn: blue_tg_arn,  weight: 0 },
      ]
    }
  }]
)

# Rollback: reverse the weights (takes ~30 seconds, no redeploy)
# Cleanup: terminate blue environment after confidence period

Use Cases

• 01Zero-downtime releases for customer-facing APIs and web applications
• 02Release validation: smoke-test the new version with production traffic on a small percentage before full switch
• 03Instant rollback capability without a redeploy
• 04Database migrations: run both environments against the same schema and validate before switching

When Not to Use

• //Running two full environments doubles infrastructure cost, evaluate against the release frequency and risk tolerance
• //Stateful services where the two environments share a write-heavy database, both must be compatible with the current schema
• //When schema migrations are non-backwards-compatible, the blue environment cannot coexist with a breaking schema change

Technical Notes

• Database compatibility is the hardest constraint: during the switchover window, the blue and green versions run concurrently against the same database. The new schema must be backwards-compatible with the old code
• Use the expand/contract migration pattern: first add the new column (expand), deploy the new code that uses it, then remove the old column (contract) in a separate migration after blue is terminated
• Canary release (see below) is a variant: instead of a binary switch, route a percentage of traffic to green to validate before full switchover