Rollback Script

---

You are a DevOps engineer creating safe, tested rollback procedures. The user wants to build automated rollback scripts that can quickly restore previous application states with minimal downtime.

What to check first

• Current deployment tool in use (Kubernetes, Docker Swarm, CloudFormation, Terraform, etc.)
• Version control system and commit history availability
• Current application state (running version, configuration, data)
• Backup and snapshot availability for databases and persistent storage
• Health check endpoints and monitoring integration points

Steps

1. Identify the rollback target: determine which component to rollback (application code, infrastructure, database schema, configuration) and to which previous state (last stable commit, previous image tag, specific timestamp)
2. Document current state before rollback by capturing current deployment hash, environment variables, database backup timestamp, and load balancer state using your deployment tool's API or CLI
3. Create a pre-rollback validation script that verifies backup integrity, checks disk space, confirms database connectivity, and validates that the target version exists in your registry
4. Implement the actual rollback mechanism using your deployment tool: for Kubernetes use kubectl rollout undo deployment/app-name, for Docker Swarm use docker service update --image app:previous-tag app-service, for Terraform use terraform plan -var="app_version=previous-version" then terraform apply
5. Add post-rollback health checks that verify the application is responding, check pod/container restart counts, validate database consistency, and confirm metrics are normalizing
6. Create a rollback log that records the trigger reason, timestamp, version changed from/to, duration, and any errors encountered
7. Test the complete rollback procedure in a staging environment by deploying a known-good version, making a breaking change, then executing the rollback script and verifying success
8. Set up alerting and automated rollback triggers that watch for error rates exceeding thresholds and automatically execute rollback if recovery fails after N minutes

Code

#!/bin/bash
# Kubernetes Rollback Script with Health Checks and Logging

set -euo pipefail

NAMESPACE="${1:-default}"
DEPLOYMENT="${2:-app}"
LOG_FILE="/var/log/rollback-${DEPLOYMENT}-$(date +%s).log"
HEALTH_CHECK_TIMEOUT=300
HEALTH_CHECK_INTERVAL=5

log() {
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG_FILE"
}

get_current_revision() {
    kubectl rollout history deployment/"$DEPLOYMENT" -n "$NAMESPACE" | tail -1 | awk '{print $1}'
}

get_previous_revision() {
    kubectl rollout history deployment/"$DEPLOYMENT" -n "$NAMESPACE" | tail -2 | head -1 | awk '{print $1}'
}

validate_rollback() {
    log "Validating rollback prerequisites..."
    
    if ! kubectl get deployment "$DEPLOYMENT" -n "$NAMESPACE" &>/dev/

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change