Rollback Deploy
Rollback deployment to previous version with safety checks, database considerations, and monitoring
npx claude-code-templates@latest --command deployment/rollback-deploy Scanned by NVIDIA SkillSpector
Automated static analysis (no LLM) · v2.12.0 · 2026-10-23
Partial analysis: some checks could not run on this component.
SkillSpector looks for patterns such as shell commands, credential access, network calls or unpinned dependencies. An observation is something worth reading in the files before you install, not a confirmed vulnerability. Components that run code locally, like hooks, MCP servers and security tooling, naturally show more of them.
- Session PersistenceRogue Agent · rollback-deploy.md:144
- Sudo/Root Execution ×3Privilege Escalation · rollback-deploy.md:128
- External Transmission ×9Data Exfiltration · rollback-deploy.md:13
Learn more about NVIDIA SkillSpector.
Content
Deployment Rollback
Rollback deployment to previous version: $ARGUMENTS
Current Deployment State
- Current version: !
curl -s https://api.example.com/version 2>/dev/null || kubectl get deployments -o wide 2>/dev/null | head -3 || echo "Version detection needed" - Available versions: !
git tag --sort=-version:refname | head -5 - Container status: !
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}" 2>/dev/null | head -5 || echo "No containers" - K8s deployments: !
kubectl get deployments 2>/dev/null || echo "No K8s access" - Health status: !
curl -sf https://api.example.com/health 2>/dev/null && echo "✅ Healthy" || echo "❌ Unhealthy"
Emergency Rollback Protocol
Systematic rollback procedure: $ARGUMENTS
Incident Assessment and Decision
- Assess the severity and impact of the current deployment issues
- Determine if rollback is necessary or if forward fix is better
- Identify affected systems, users, and business functions
- Consider data integrity and consistency implications
- Document the decision rationale and timeline
Emergency Response Setup
bash# Activate incident response team # Set up communication channels # Notify stakeholders immediately # Example emergency notification echo "🚨 ROLLBACK INITIATED Issue: Critical performance degradation after v1.3.0 deployment Action: Rolling back to v1.2.9 ETA: 15 minutes Impact: Temporary service interruption possible Status channel: #incident-rollback-202401"Pre-Rollback Safety Checks
bash# Verify current production version curl -s https://api.example.com/version kubectl get deployments -o wide # Check system status curl -s https://api.example.com/health | jq . # Identify target rollback version git tag --sort=-version:refname | head -5 # Verify rollback target exists and is deployable git show v1.2.9 --statDatabase Considerations
bash# Check for database migrations since last version ./check-migrations.sh v1.2.9 v1.3.0 # If migrations exist, plan database rollback # WARNING: Database rollbacks can cause data loss # Consider forward fix instead if migrations are present # Create database backup before rollback ./backup-database.sh "pre-rollback-$(date +%Y%m%d-%H%M%S)"Traffic Management Preparation
bash# Prepare to redirect traffic # Option 1: Maintenance page ./enable-maintenance-mode.sh # Option 2: Load balancer management ./drain-traffic.sh --gradual # Option 3: Circuit breaker activation ./activate-circuit-breaker.shContainer/Kubernetes Rollback
bash# Kubernetes rollback kubectl rollout history deployment/app-deployment kubectl rollout undo deployment/app-deployment # Or rollback to specific revision kubectl rollout undo deployment/app-deployment --to-revision=3 # Monitor rollback progress kubectl rollout status deployment/app-deployment --timeout=300s # Verify pods are running kubectl get pods -l app=your-appDocker Swarm Rollback
bash# List service history docker service ps app-service --no-trunc # Rollback to previous version docker service update --rollback app-service # Or update to specific image docker service update --image app:v1.2.9 app-service # Monitor rollback docker service ps app-serviceTraditional Deployment Rollback
bash# Blue-Green deployment rollback ./switch-to-blue.sh # or green, depending on current # Rolling deployment rollback ./deploy-version.sh v1.2.9 --rolling # Symlink-based rollback ln -sfn /releases/v1.2.9 /current sudo systemctl restart app-serviceLoad Balancer and CDN Updates
bash# Update load balancer to point to old version aws elbv2 modify-target-group --target-group-arn $TG_ARN --targets Id=old-instance # Clear CDN cache if needed aws cloudfront create-invalidation --distribution-id $DIST_ID --paths \"/*\" # Update DNS if necessary (last resort, has propagation delay) # aws route53 change-resource-record-sets ...Configuration Rollback
bash\n # Rollback configuration files\n git checkout v1.2.9 -- config/\n \n # Restart services with old configuration\n sudo systemctl restart nginx\n sudo systemctl restart app-service\n \n # Rollback environment variables\n ./restore-env-vars.sh v1.2.9\n \n # Update feature flags\n ./update-feature-flags.sh --disable-new-features\n\n\n11. Database Rollback (if necessary)\nsql\n -- EXTREME CAUTION: Can cause data loss\n \n -- Check migration status\n SELECT * FROM schema_migrations ORDER BY version DESC LIMIT 5;\n \n -- Rollback specific migrations (framework dependent)\n -- Rails: rake db:migrate:down VERSION=20240115120000\n -- Django: python manage.py migrate app_name 0001\n -- Node.js: npm run migrate:down\n \n -- Verify database state\n SHOW TABLES;\n DESCRIBE critical_table;\n\n\n12. Service Health Validation\nbash\n # Health check script\n #!/bin/bash\n \n echo \"Validating rollback...\"\n \n # Check application health\n if curl -f -s https://api.example.com/health > /dev/null; then\n echo \"✅ Health check passed\"\n else\n echo \"❌ Health check failed\"\n exit 1\n fi\n \n # Check critical endpoints\n endpoints=(\n \"/api/users/me\"\n \"/api/auth/status\"\n \"/api/data/latest\"\n )\n \n for endpoint in \"${endpoints[@]}\"; do\n if curl -f -s \"https://api.example.com$endpoint\" > /dev/null; then\n echo \"✅ $endpoint working\"\n else\n echo \"❌ $endpoint failed\"\n fi\n done\n\n\n13. Performance and Metrics Validation\nbash\n # Check response times\n curl -w \"Response time: %{time_total}s\\n\" -s -o /dev/null https://api.example.com/\n \n # Monitor error rates\n tail -f /var/log/app/error.log | head -20\n \n # Check system resources\n top -bn1 | head -10\n free -h\n df -h\n \n # Validate database connectivity\n mysql -u app -p -e \"SELECT 1;\"\n\n\n14. Traffic Restoration\nbash\n # Gradually restore traffic\n ./restore-traffic.sh --gradual\n \n # Disable maintenance mode\n ./disable-maintenance-mode.sh\n \n # Re-enable circuit breakers\n ./deactivate-circuit-breaker.sh\n \n # Monitor traffic patterns\n ./monitor-traffic.sh --duration 300\n\n\n15. Monitoring and Alerting\nbash\n # Enable enhanced monitoring during rollback\n ./enable-enhanced-monitoring.sh\n \n # Watch key metrics\n watch -n 10 'curl -s https://api.example.com/metrics | jq .'\n \n # Monitor logs in real-time\n tail -f /var/log/app/*.log | grep -E \"ERROR|WARN|EXCEPTION\"\n \n # Check application metrics\n # - Response times\n # - Error rates\n # - User sessions\n # - Database performance\n\n\n16. User Communication\nmarkdown\n ## Service Update - Rollback Completed\n \n **Status:** ✅ Service Restored\n **Time:** 2024-01-15 15:45 UTC\n **Duration:** 12 minutes of degraded performance\n \n **What Happened:**\n We identified performance issues with our latest release and \n performed a rollback to ensure optimal service quality.\n \n **Current Status:**\n - All services operating normally\n - Performance metrics back to baseline\n - No data loss occurred\n \n **Next Steps:**\n We're investigating the root cause and will provide updates \n on our status page.\n\n\n17. Post-Rollback Validation\nbash\n # Extended monitoring period\n ./monitor-extended.sh --duration 3600 # 1 hour\n \n # Run integration tests\n npm run test:integration:production\n \n # Check user-reported issues\n ./check-support-tickets.sh --since \"1 hour ago\"\n \n # Validate business metrics\n ./check-business-metrics.sh\n\n\n18. Documentation and Reporting\nmarkdown\n # Rollback Incident Report\n \n **Incident ID:** INC-2024-0115-001\n **Rollback Version:** v1.2.9 (from v1.3.0)\n **Start Time:** 2024-01-15 15:30 UTC\n **End Time:** 2024-01-15 15:42 UTC\n **Total Duration:** 12 minutes\n \n **Timeline:**\n - 15:25 - Performance degradation detected\n - 15:30 - Rollback decision made\n - 15:32 - Traffic drained\n - 15:35 - Rollback initiated\n - 15:38 - Rollback completed\n - 15:42 - Traffic fully restored\n \n **Impact:**\n - 12 minutes of degraded performance\n - ~5% of users experienced slow responses\n - No data loss or corruption\n - No security implications\n \n **Root Cause:**\n Memory leak in new feature causing performance degradation\n \n **Lessons Learned:**\n - Need better performance testing in staging\n - Improve monitoring for memory usage\n - Consider canary deployments for major releases\n\n\n19. Cleanup and Follow-up\nbash\n # Clean up failed deployment artifacts\n docker image rm app:v1.3.0\n \n # Update deployment status\n ./update-deployment-status.sh \"rollback-completed\"\n \n # Reset feature flags if needed\n ./reset-feature-flags.sh\n \n # Schedule post-incident review\n ./schedule-postmortem.sh --date \"2024-01-16 10:00\"\n\n\n20. Prevention and Improvement\n - Analyze what went wrong with the deployment\n - Improve testing and validation procedures\n - Enhance monitoring and alerting\n - Update rollback procedures based on learnings\n - Consider implementing canary deployments\n\nRollback Decision Matrix:\n\n| Issue Severity | Data Impact | Time to Fix | Decision |\n|---------------|-------------|-------------|----------|\n| Critical | None | > 30 min | Rollback |\n| High | Minor | > 60 min | Rollback |\n| Medium | None | > 2 hours | Consider rollback |\n| Low | None | Any | Forward fix |\n\nEmergency Rollback Script Template:\nbash\n#!/bin/bash\nset -e\n\n# Emergency rollback script\nPREVIOUS_VERSION=\"${1:-v1.2.9}\"\nCURRENT_VERSION=$(curl -s https://api.example.com/version)\n\necho \"🚨 EMERGENCY ROLLBACK\"\necho \"From: $CURRENT_VERSION\"\necho \"To: $PREVIOUS_VERSION\"\necho \"\"\n\n# Confirm rollback\nread -p \"Proceed with rollback? (yes/no): \" confirm\nif [ \"$confirm\" != \"yes\" ]; then\n echo \"Rollback cancelled\"\n exit 1\nfi\n\n# Execute rollback\necho \"Starting rollback...\"\nkubectl set image deployment/app-deployment app=app:$PREVIOUS_VERSION\nkubectl rollout status deployment/app-deployment --timeout=300s\n\n# Validate\necho \"Validating rollback...\"\nsleep 30\ncurl -f https://api.example.com/health\n\necho \"✅ Rollback completed successfully\"\n\n\nRemember: Rollbacks should be a last resort. Always consider forward fixes first, especially when database migrations are involved.