Releases, Upgrades & Rollbacks

In one line

Every helm install or upgrade creates a new, numbered revision of a named release — helm rollback is the exact same safety net as kubectl rollout undo, just at the whole-chart level instead of a single Deployment.

0/4 · 0%

Key ideas

01
A RELEASE is one specific, named installation of a chart in a cluster — the same chart can have many separate releases (Topic 7.2's release-a/release-b example), each tracked completely independently, with its own history and its own current set of configured values.
02
Every helm install or helm upgrade against a release creates a new, numbered REVISION — Helm keeps a genuine history of every past revision's exact configuration (which values were used, which chart version), directly mirroring the ReplicaSet-based revision history a plain Deployment keeps (Phase 6.3), just at the level of the whole chart's combined set of resources instead of one Deployment alone.
03
helm upgrade <release-name> <chart> updates an EXISTING release to a new chart version and/or new values — Helm calculates the difference between the currently-deployed state and the new desired state, and applies only what's actually changed, using the exact same underlying rolling-update mechanics (Phase 6.3) for any Deployments involved.
04
helm rollback <release-name> <revision-number> reverts an entire release back to a specific PAST revision — genuinely the same safety net as kubectl rollout undo, just operating on potentially many resources at once (every Deployment, Service, ConfigMap the chart manages) rather than a single Deployment in isolation.
05
helm uninstall <release> removes every resource the release created (add --keep-history to keep its revision history for later inspection). It does NOT delete PersistentVolumeClaims created by StatefulSets or CRDs installed from a chart's crds/ folder, which is deliberate protection for data you must clean up explicitly.
06
helm history <release-name> shows every past revision with its status, chart version, and app version — the direct equivalent of kubectl rollout history, giving you the full picture needed to decide exactly which revision to roll back to if something goes wrong, rather than only ever being able to go back one step.
07
helm upgrade --install (combining both operations into one command) INSTALLS the release if it doesn't already exist, or UPGRADES it if it does — genuinely useful in automated deployment scripts and CI/CD pipelines (Git's own course covered this exact 'declarative, works whether it exists or not' philosophy for kubectl apply, Phase 6 of Kubernetes itself; Helm's --install flag brings that same idempotent convenience to chart-based deployments).

Code & diagrams

HelmRevisionHistorydiagram

Every upgrade creates a new revision; rollback simply targets an older one — the exact same idea as kubectl rollout undo.

Rendering diagram…

releases-and-rollbacks.shmarkdown

Install, upgrade, break on purpose, and recover — the complete Helm release lifecycle.

# Initial install — this is revision 1
helm install my-release ./my-app-chart

# An upgrade — new chart version and/or new values — this becomes revision 2
helm upgrade my-release ./my-app-chart --set image.tag=1.6.0

# See the full revision history
helm history my-release
# REVISION  STATUS      CHART            APP VERSION
# 1         superseded  my-app-chart-1.0.0  1.5.0
# 2         deployed    my-app-chart-1.0.0  1.6.0

# Deliberately roll out something broken — revision 3
helm upgrade my-release ./my-app-chart --set image.tag=1.7.0-broken

# Roll back to the last known-good revision
helm rollback my-release 2
helm history my-release
# a NEW revision 4 appears, with the SAME config as revision 2

# The idempotent, CI/CD-friendly pattern — works whether it exists or not
helm upgrade --install my-release ./my-app-chart --set image.tag=1.6.0

Explain it without notes

Why does helm rollback create a brand-new revision number, rather than literally deleting the bad revision and reverting the counter?

Why is helm upgrade --install genuinely useful specifically in an automated CI/CD pipeline, compared to plain helm install or helm upgrade alone?

Practice

Install a chart, upgrade it at least twice with different values, and use helm history to see the full revision timeline.

Deliberately upgrade to a broken configuration, then use helm rollback to return to the last known-good revision, confirming with helm history that a new revision was created rather than the old one being deleted.

Trade-offs

↔
Helm's revision tracking and rollback give genuinely strong safety nets at the whole-release level, but a rollback only reverts the CHART-MANAGED resources and their configuration — it doesn't automatically undo something like a database migration that a hook (Topic 7.4) might have run as part of that upgrade, which is exactly why genuinely safe production rollouts often need additional care (backward-compatible migrations, careful hook design) beyond what helm rollback alone can guarantee.

Done when you can

I understand a release's revision history and how upgrades add to it.
I can use helm rollback to revert a release to a specific past revision.
I understand why helm upgrade --install is the standard pattern for automated deployment pipelines.