Skip to main content
Rollback is a foundational capability in modern DevOps and release engineering: the ability to revert a change and restore a previous, known-good version of a component or environment quickly and reliably. Definition
  • Rollback: the process of reverting a change to its previous version to restore a stable state.
Why rollbacks matter
  • Minimize downtime by restoring a known-good release quickly.
  • Preserve observability and diagnostic context so teams can investigate incidents.
  • Enable safer migrations by keeping older artifacts until integrations are validated.
  • Make rollbacks auditable and repeatable when automated through CI/CD and IaC tooling.
Typical rollback scenario
  1. You build a new version of a component and the CI/CD pipeline deploys it to a Kubernetes cluster or another environment.
  2. After deployment, you detect a problem in the cluster or in application behavior (e.g., increased errors, degraded performance, failed health checks).
  3. To recover quickly, you trigger a rollback. The pipeline or operator redeploys the previous stable version.
  4. After the rollback completes, the environment should return to the prior working state while you diagnose and fix the root cause.
Rollback in Kubernetes and Helm Common Kubernetes commands for rollbacks: 
# Inspect rollout history for a deployment
kubectl rollout history deployment/my-app

# Roll back to the previous revision
kubectl rollout undo deployment/my-app

# Roll back to a specific revision (if available)
kubectl rollout undo deployment/my-app --to-revision=2
For Helm-managed releases: 
helm history my-release
helm rollback my-release 1
Quick reference table
ToolActionCommand example
KubernetesShow rollout historykubectl rollout history deployment/my-app
KubernetesRoll back to previous revisionkubectl rollout undo deployment/my-app
KubernetesRoll back to specific revisionkubectl rollout undo deployment/my-app --to-revision=2
HelmShow release historyhelm history my-release
HelmRoll back to a specific releasehelm rollback my-release 1
The image illustrates a software rollback process, showing the transition from a new component (v2.1) back to an old stable component (v1.9) within a CI/CD pipeline. It emphasizes retaining version 1.9 until all integrations are validated.
Thinking about the environment’s sustainability, it’s important to keep older versions around while not all components are migrated. Erasing older artifacts or images should only be done once all integrations have been validated and the migration solution has earned your trust.
Keep build artifacts, deployment manifests, and image tags for a reasonable retention period. This ensures you can quickly redeploy a known-good version without relying on rebuilds that may produce different artifacts.
Be cautious with stateful or schema-changing migrations. Rolling back code without rolling back incompatible database schema changes can leave the system in an unusable state. Coordinate application, schema, and data migrations with clear forward/backward compatibility strategies.
The image is an infographic titled "Rollback," outlining four steps: protecting the environment during bad deployments, reverting to stable versions using CI/CD and IaC, maintaining observability during issues, and removing old versions after validation.
Best practices
  • Automate rollback paths where possible and test them regularly as part of your deployment pipeline.
  • Retain artifacts (images, manifests, Helm charts) for a defined retention window to guarantee reproducibility.
  • Maintain full observability (logs, metrics, traces) before and after rollbacks to speed root-cause analysis.
  • Use feature flags and progressive rollouts (canary, blue/green) to reduce blast radius and make rollback safer.
  • Document rollback runbooks and make them easily accessible to on-call teams.
Summary
  • Rollbacks are an intentional, tested part of release and migration strategies.
  • Automate rollback paths and preserve artifacts and observability so you can recover fast and investigate with full context.
  • Treat data migrations and schema changes with extra caution—ensure forward/backward compatibility or add explicit migration rollback steps.
Links and references That’s it for this lesson.

Watch Video