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
