Blue-Green Deployments

Blue-green deployment is a release strategy that eliminates deployment downtime and enables instant rollback by maintaining two identical production environments — blue and green — at all times. One environment serves live traffic while the other is idle. When a new version is ready to deploy, it is deployed to the idle environment, verified there with smoke tests and health checks, and then traffic is switched from the active environment to the newly deployed one via a load balancer or DNS change. If anything goes wrong, traffic switches back in seconds. The previously active environment is still running and has not been touched — it becomes the instant rollback target.

The Mechanics — Two Environments, One Traffic Switch

The core mechanic is straightforward. At any given moment, blue is live and green is idle — or vice versa. The pipeline always deploys to whichever environment is currently idle. After deployment and verification, a single traffic switch — a load balancer rule update, an AWS target group swap, a Kubernetes service selector update — moves all incoming requests from the old environment to the new one. The switch is near-instantaneous for new requests. In-flight requests complete against the old environment. Users experience no interruption.

Pipeline Implementation — Detecting Active and Deploying to Idle

The pipeline must determine which environment is currently active before it can deploy to the idle one. This is typically achieved by querying the load balancer or a deployment state store — a parameter in AWS Parameter Store, a label on a Kubernetes service, or a variable in a deployment database — to read which colour is currently live, then deploying to the opposite.

jobs:
  blue-green-deploy:
    runs-on: ubuntu-latest
    environment: production
    permissions:
      contents: read
      id-token: write

    steps:
      - uses: actions/checkout@v4

      - name: Authenticate to AWS via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE }}
          aws-region: eu-west-1

      - name: Determine active environment
        id: active
        run: |
          # Read which colour is currently serving traffic
          ACTIVE=$(aws ssm get-parameter \
            --name "/myapp/production/active-colour" \
            --query "Parameter.Value" \
            --output text)
          echo "active=$ACTIVE" >> $GITHUB_OUTPUT
          # Set idle to the opposite colour
          if [ "$ACTIVE" = "blue" ]; then
            echo "idle=green" >> $GITHUB_OUTPUT
          else
            echo "idle=blue" >> $GITHUB_OUTPUT
          fi

      - name: Deploy to idle environment
        run: |
          IDLE=${{ steps.active.outputs.idle }}
          echo "Deploying v${{ github.sha }} to $IDLE environment"
          aws ecs update-service \
            --cluster myapp-production \
            --service myapp-$IDLE \
            --force-new-deployment \
            --task-definition myapp:${{ github.sha }}
          aws ecs wait services-stable \
            --cluster myapp-production \
            --services myapp-$IDLE               # Wait for ECS to confirm healthy

      - name: Smoke test idle environment
        run: |
          IDLE=${{ steps.active.outputs.idle }}
          IDLE_URL=$(aws ssm get-parameter \
            --name "/myapp/production/$IDLE-url" \
            --query "Parameter.Value" --output text)
          ./smoke-test.sh "$IDLE_URL"            # Test the new version before traffic switch

      - name: Switch traffic to idle environment
        run: |
          IDLE=${{ steps.active.outputs.idle }}
          # Update load balancer to point to the newly deployed environment
          aws elbv2 modify-listener \
            --listener-arn ${{ secrets.ALB_LISTENER_ARN }} \
            --default-actions Type=forward,TargetGroupArn=$(aws ssm get-parameter \
              --name "/myapp/production/$IDLE-tg-arn" \
              --query "Parameter.Value" --output text)
          # Record the new active colour for the next deployment
          aws ssm put-parameter \
            --name "/myapp/production/active-colour" \
            --value "$IDLE" --overwrite

Database Considerations — The Blue-Green Complication

Blue-green deployment handles stateless application tiers elegantly. Databases — stateful, shared, and schema-constrained — are the complication. If both blue and green share the same database, a schema migration must be compatible with both versions simultaneously: the old version (blue) must continue to function against the migrated schema while the new version (green) also functions against it, until the traffic switch is complete and blue is decommissioned.

This constraint means that during a blue-green deployment, destructive schema changes — dropping a column, renaming a table — cannot be applied in the same release as the application code that removes the reference to that column. The expand-contract pattern (introduced in Lesson 20) is the solution: add the new column first and deploy, then migrate data, then deploy the application that uses the new column, then drop the old column in a subsequent release. Each step is independently deployable and backwards-compatible with the currently running version.

Cost, Trade-offs, and Traffic Cutover Patterns

Blue-green deployment has one significant cost: it requires double the infrastructure for the application tier. During the deployment window — the period between deploying to idle and decommissioning the old active environment — both environments are running simultaneously. For large applications on expensive infrastructure, this cost is real. The mitigation is to keep the deployment window short — measured in minutes, not hours — so the cost of running both environments is minimal relative to the operational safety gained.

Weighted traffic routing is a variant that switches traffic gradually rather than all at once — routing 5% of traffic to green, monitoring for 10 minutes, then 20%, then 50%, then 100%. This is effectively a blend of blue-green and canary deployment (covered in Lesson 34). It provides the safety of incremental exposure while retaining the instant rollback capability of blue-green — at any point during the weighted transition, routing 100% back to blue is a single parameter change.

Practice Questions

Answer in your own words — then check against the expected answer.

Lesson Quiz