Helm Release Lifecycle: Install, Upgrade, Rollback, History

Helm is more than a templating tool — it's a release manager. Every helm install or upgrade creates a release record stored as a Kubernetes Secret in the target namespace, containing the rendered manifests, the merged values, and the status. This record is what makes helm history, helm rollback, and helm get manifest work without any external database.

The CI pattern

• helm upgrade --install order-svc ./chart -f values-prod.yaml --set image.tag=$SHA --atomic --timeout 5m --wait.
• --install makes it idempotent — install if absent, upgrade if present — safe to run every deploy.
• --atomic is the most important flag — if apply or readiness wait fails, Helm rolls back to the previous revision; the cluster is never in a half-applied state.
• --wait blocks until all resources are Ready; --timeout 5m sets the ceiling.

History and rollback

• helm history order-svc lists every revision with status: deployed, superseded, failed.
• helm rollback order-svc 3 reverts to revision 3 — re-applies the Deployment, Service, ConfigMap as they were at that revision. Creates a new revision (e.g., 7) that mirrors 3.
• helm get manifest order-svc --revision 3 shows exactly what was applied at that point — essential for incident reviews.
• What rollback does NOT do: reverse hook side-effects (DB migrations) or restore external data. Design migrations to be forward-compatible so a rollback of manifests doesn't leave DB schema orphaned.

Hooks for migrations

• Jobs annotated helm.sh/hook: pre-upgrade run before the new manifests apply; use for DB migrations.
• helm.sh/hook-weight orders hooks; low runs first.
• helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded cleans up Job history.
• helm test runs test-annotated pods post-deploy for smoke tests.

Why Helm beats raw kubectl apply

• kubectl apply has no history — you rely on Git to know what was applied, and nothing prevents drift between Git and cluster.
• Helm stores the actual applied manifests per revision, so rollback works even if Git is gone.
• --atomic gives safe failure handling that raw apply cannot match.

Interaction with GitOps

• ArgoCD can deploy Helm charts but often uses helm template mode — it renders and applies itself, so helm history is empty; rollback = Git revert.
• Flux Helm Controller uses real Helm releases — native helm history and rollback are preserved.
• In strict GitOps shops Git is the source of truth — manual helm rollback diverges and gets reverted by the GitOps controller.

Common gotchas

• CRDs in the crds/ folder are install-only — upgrades don't touch them and rollback doesn't revert them.
• Don't kubectl-edit Helm-managed resources — your edits vanish on next upgrade because of 3-way merge.
• revisionHistoryLimit caps retained revisions; raise for frequent-deploy services to have a longer rollback window.