Helm install, upgrade, rollback — the operational lifecycle

The Helm operational lifecycle is install, upgrade, rollback. This lesson walks the commands, the safety flags, the dry-run, the diff plugin, the CI/CD integration, and the operational discipline.

helm install

helm install myrelease mychart/ \
  -n prod-app \
  -f values.yaml \
  -f values-prod.yaml \
  --version 1.0.0 \
  --atomic \
  --wait \
  --timeout 5m \
  --create-namespace

The flags:

• -n prod-app — target namespace.
• -f values.yaml and -f values-prod.yaml — values files.
• --version 1.0.0 — pin chart version (always in production).
• --atomic — if the install fails, roll back automatically.
• --wait — wait for all resources to be ready.
• --timeout 5m — fail if not ready within 5 minutes.
• --create-namespace — create the namespace if it does not exist.

helm upgrade

helm upgrade myrelease mychart/ \
  -n prod-app \
  -f values.yaml \
  -f values-prod.yaml \
  --version 1.1.0 \
  --atomic \
  --wait \
  --timeout 5m \
  --reuse-values

The upgrade flags:

• --reuse-values — reuse the values from the previous release; only override what’s specified. Useful when the previous release had manual adjustments.
• --atomic — if the upgrade fails, roll back to the previous revision.
• --wait — wait for resources.
• --timeout 5m — fail if not ready.

The upgrade creates a new revision; if it fails, the release is rolled back to the previous revision.

—atomic and rollback

flowchart TD
    A[helm upgrade --atomic] --> B{Render manifests}
    B --> C[Apply manifests]
    C --> D{Resources ready?}
    D -->|Yes| E["Upgrade complete, new revision"]
    D -->|No| F[Rollback to previous revision]
    F --> G[Resources restored to previous state]

--atomic is the safety net for upgrades:

1. Render the new manifests.
2. Apply them.
3. If resources are not ready within the timeout, roll back to the previous revision.

The rollback is automatic; no human intervention is required.

helm rollback

helm rollback myrelease 2 -n prod-app \
  --wait \
  --timeout 5m \
  --cleanup-on-fail

Rolls back to revision 2. The rollback creates a new revision (e.g., revision 4 if revision 3 was the failed upgrade); the rolled-back state is preserved in history.

—dry-run

helm install myrelease mychart/ \
  --dry-run \
  --debug \
  -f values.yaml

--dry-run shows what would happen without applying anything. The output is the rendered YAML manifests.

The discipline is to always dry-run in CI before production, and to review the dry-run output for unexpected changes.

helm-diff plugin

helm diff upgrade myrelease mychart/ \
  -f values.yaml \
  --version 1.1.0

The helm-diff plugin shows the diff between the current release and the proposed upgrade. This is essential for review — without diff, an upgrade may include changes the operator did not expect.

mychart/templates/deployment.yaml:
- replicas: 3
+ replicas: 5

mychart/templates/service.yaml:
  (no changes)

CI/CD integration

flowchart LR
    A[Git commit] --> B["CI: helm lint, helm template, helm diff"]
    B --> C["Argo CD / Flux / helmfile"]
    C --> D[helm upgrade --atomic --wait]
    D --> E[Cluster]

Production CI/CD for Helm:

1. Lint. helm lint mychart/ checks the chart for syntax errors.
2. Template. helm template mychart/ renders the manifests.
3. Diff. helm diff upgrade shows the changes.
4. Review. The diff is reviewed in the PR.
5. Deploy. Argo CD, Flux, or helmfile applies the upgrade with --atomic --wait.

Quiz

The operational discipline

Helm lifecycle in production rests on five non-negotiable elements:

• Pin chart and app versions. Never latest in production.
• —atomic for safety. Upgrades roll back on failure.
• —wait and —timeout. Wait for resources to be ready.
• —dry-run and diff before production. Always review the diff.
• Test in staging first. A chart change that breaks in production is a hot rollback.

Helm upgrades are production events. Treat them with the same rigour as any other production change.