---

name: deployment-strategies disable-model-invocation: true description: | Production deployment strategies. Blue-green, canary, rolling update, recreate. Zero-downtime deployments, rollback procedures, database migration coordination, and deployment automation.

USE WHEN: user mentions "blue-green", "canary deployment", "rolling update", "zero-downtime", "deployment strategy", "rollback", "deploy pipeline"

DO NOT USE FOR: CI/CD pipeline syntax - use github-actions; container orchestration - use kubernetes; IaC - use terraform allowed-tools: Read, Grep, Glob, Write, Edit

Deployment Strategies

Strategy Comparison

Strategy	Downtime	Risk	Rollback Speed	Resource Cost
Recreate	Yes	High	Slow (redeploy)	Low
Rolling Update	No	Medium	Medium	Low
Blue-Green	No	Low	Instant (switch)	2x resources
Canary	No	Very Low	Fast (route shift)	+10-20%

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

Anti-Pattern	Fix
Deploy + migrate in one step	Separate deployment from migration
Destructive DB migrations	Use expand-contract pattern
No health checks for readiness	Configure readiness probes
No automated rollback trigger	Set error rate thresholds
Manual deployments	Automate via CI/CD pipeline

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