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