deployment-strategies

# Deployment Strategies Safe deployment patterns with verification and rollback. ## Rolling Deployment (Kubernetes) ```bash # Update image (triggers rolling update) kubectl set image deployment/myapp myapp=myapp:v2.0 # Watch rollout progress kubectl rollout status deployment/myapp # Check rollout history kubectl rollout history deployment/myapp # Rollback to previous version kubectl rollout undo deployment/myapp # Rollback to specific revision kubectl rollout undo deployment/myapp --to-revision=3 # Pause/resume rollout kubectl rollout pause deployment/myapp kubectl rollout resume deployment/myapp ``` ## Blue-Green Deployment ```bash # Deploy green (new version) alongside blue (current) kubectl apply -f deployment-green.yaml # Verify green is healthy kubectl get pods -l version=green kubectl exec -it $(kubectl get pod -l version=green -o jsonpath='{.items[0].metadata.name}') -- curl -s localhost:8080/health # Switch traffic to green kubectl patch service myapp -p '{"spec":{"selector":{"version":"green"}}}' # Verify traffic is flowing to green curl -s https://myapp.example.com/version # Rollback: switch back to blue kubectl patch service myapp -p '{"spec":{"selector":{"version":"blue"}}}' # Cleanup old blue after confidence period kubectl delete deployment myapp-blue ``` ## Canary Deployment ```bash # Deploy canary (small replica count) kubectl apply -f deployment-canary.yaml kubectl scale deployment myapp-canary --replicas=1 # Main deployment stays at full capacity kubectl get deployment myapp --show-labels kubectl get deployment myapp-canary --show-labels # Monitor canary error rate kubectl logs -l version=canary --tail=100 | grep -c "ERROR" # Promote canary: scale up canary, scale down main kubectl scale deployment myapp-canary --replicas=5 kubectl scale deployment myapp --replicas=0 # Or rollback: remove canary kubectl delete deployment myapp-canary ``` ## GitHub Actions Deployment ```bash # Trigger deployment workflow gh workflow run deploy.yml -f environment=staging -f version=v2.0 # Watch deployment gh run watch $(gh run list --workflow=deploy.yml --limit 1 --json databaseId -q '.[0].databaseId') # Check deployment status gh api repos/{owner}/{repo}/deployments --jq '.[] | {id, environment: .environment, ref: .ref, created_at: .created_at}' | head -20 ``` ## Docker Compose (Simple) ```bash # Pull new images docker compose pull # Rolling restart (zero downtime with multiple replicas) docker compose up -d --no-deps --scale myapp=2 myapp sleep 10 docker compose up -d --no-deps --scale myapp=1 myapp # Quick rollback: use previous image tag docker compose up -d myapp ``` ## Post-Deployment Verification ```bash # Health check curl -sf https://myapp.example.com/health | jq . # Smoke test critical endpoints endpoints=("/api/users" "/api/products" "/api/health") for ep in "${endpoints[@]}"; do status=$(curl -s -o /dev/null -w "%{http_code}" "https://myapp.example.com$ep") echo "$ep: $status" done # Check error rate in logs (last 5 minutes) kubectl logs -l app=myapp --since=5m | grep -c "ERROR" # Check response times for i in $(seq 1 5); do curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s Total: %{time_total}s\n" https://myapp.example.com/ done ``` ## Notes - Always deploy to staging first. Verify before promoting to production. - Blue-green requires 2x resources during transition. Budget for it. - Canary catches issues that staging misses (real traffic patterns, data shapes, scale). - Automated rollback triggers: error rate > 1%, p95 latency > 2x baseline, health check failures. - Keep at least 3 previous versions available for quick rollback.