Deployment Strategies

Strategy Comparison

Blue-Green Deployment

                    ┌─── Blue (v1) ← current traffic
Load Balancer ──────┤
                    └─── Green (v2) ← deploy here, test, then switch

AWS (ALB Target Groups)

// Switch traffic from blue to green
await elbv2.modifyListener({
  ListenerArn: listenerArn,
  DefaultActions: [{
    Type: 'forward',
    TargetGroupArn: greenTargetGroupArn, // Point to green
  }],
});

// Rollback: point back to blue
await elbv2.modifyListener({
  ListenerArn: listenerArn,
  DefaultActions: [{
    Type: 'forward',
    TargetGroupArn: blueTargetGroupArn,
  }],
});

Canary Deployment

# Kubernetes: Argo Rollouts
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5        # 5% traffic to canary
        - pause: { duration: 5m }
        - setWeight: 20
        - pause: { duration: 10m }
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100       # Full rollout
      analysis:
        templates:
          - templateName: error-rate
        startingStep: 1        # Start checking from step 1

Rolling Update (Kubernetes)

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1    # At most 1 pod down
      maxSurge: 1          # At most 1 extra pod

Database Migration Coordination

1. Deploy v2 code (backward-compatible with v1 schema)
2. Run forward migration (additive only: new columns, tables)
3. Verify v2 works correctly
4. Run cleanup migration (remove old columns) in next release

Expand-Contract Pattern

-- Release 1: EXPAND (add new column)
ALTER TABLE users ADD COLUMN full_name TEXT;
UPDATE users SET full_name = first_name || ' ' || last_name;

-- Release 2: code uses full_name, stops writing first_name/last_name

-- Release 3: CONTRACT (remove old columns)
ALTER TABLE users DROP COLUMN first_name, DROP COLUMN last_name;

Rollback Checklist

# 1. Detect issue (automated or manual)
# 2. Route traffic back to previous version
kubectl rollout undo deployment/my-app

# 3. Verify rollback successful
kubectl rollout status deployment/my-app

# 4. If DB migration was run, execute backward migration
# (only if migration was backward-compatible)

Anti-Patterns

Production Checklist

• Zero-downtime strategy chosen (rolling/blue-green/canary)
• Health checks configured (liveness + readiness)
• Rollback procedure documented and tested
• Database migrations backward-compatible
• Automated rollback on error rate spike
• Deployment notifications to team