Upgrades, History and Rollbacks

Every change is a revision

helm upgrade RELEASE CHART renders the chart with the new values and applies the difference to the cluster, creating a new revision. In pipelines, helm upgrade --install is the usual form: it installs the release if it does not exist and upgrades it otherwise, so the same command works on the first and the hundredth deployment. Add --wait so Helm waits until Deployments are ready (and --timeout to bound it); without it, Helm reports success as soon as the API accepts the objects, even if pods then crash. helm history lists revisions with their status and chart version, and helm rollback RELEASE REVISION re-applies an earlier revision's manifests as a new revision. Rollback restores Kubernetes objects, not data: a database migration run by the new version is not undone. Limit stored revisions with --history-max (default 10 for upgrades).

Upgrade, observe, roll back

A failed upgrade leaves the release in a failed state; rollback returns to a known-good revision.

helm upgrade --install shop-api ./charts/shop-api -n shop \
  -f values-prod.yaml --set image.tag=2.8.0 \
  --wait --timeout 5m

# lists each revision with its status (deployed, superseded, failed), chart and description
helm history shop-api -n shop

# suppose revision 5 failed and revision 4 was good:
helm rollback shop-api 4 -n shop --wait   # creates revision 6 with revision 4's manifests

Undo history in a document editor

Each upgrade is a saved version of the document. Rolling back restores the text from an older version, but if you emailed a copy to someone in between (a database migration), undo cannot recall the email.

Quick check: Why add --wait to helm upgrade in a CI pipeline?

• It makes rendering faster
• So the command fails if workloads do not become ready, instead of reporting success too early
• It skips hooks
• It deletes old revisions