Kubernetes Rollback: kubectl undo, Helm rollback, GitOps revert

Three rollback methods, each suited for a different situation — and one trap that breaks all of them.

The fastest — `kubectl rollout undo`

• Reverts a Deployment to its previous ReplicaSet; takes 30 seconds; no rebuild, no registry pull, no commit
• Use during an active incident when speed matters most; the SRE on-call rolls back, the incident is resolved, then the team fixes it properly in code
• Limitation: only the Deployment object is reverted; if the release also changed a ConfigMap or Service, those changes remain

The chart-aware — `helm rollback`

• Reverts an entire Helm release to a previous revision; Deployment, ConfigMap, Service, Ingress all revert atomically
• helm history payment-service shows previous revisions; helm rollback payment-service 7 restores revision 7
• Use for Helm-managed services; covers the multi-resource case that kubectl undo misses

The audited standard — GitOps revert

• ArgoCD or Flux watches a manifest repo; reverting the bad commit and pushing triggers a re-sync; cluster reconciles to the previous manifest
• Slower than the other two (2–5 minutes) but the only one with a clean audit trail and consistency with the cluster's source of truth
• The right standard for any team running GitOps; the others become emergency tools used only during incidents

The trap — database migrations

• Code rollback only works if database migrations are backward-compatible; adding a column is safe (old code ignores it); dropping a column breaks rollback
• Use the expand-contract pattern: add new column, deploy code that writes both, deploy code that reads new, only later drop the old column — each step independently revertible
• Never combine a code change and a destructive migration in the same release; you've made rollback impossible without data loss

Operational discipline

• Run rollback drills in staging monthly; a never-tested rollback is broken; the first test should never be a real incident
• Set revisionHistoryLimit to 20–50 for active services so you have rollback targets; keep image registry retention long enough that pull-back works