Helm upgrade and rollback workflow

WHAT THIS TESTS Whether you treat a Helm release as a versioned, revisioned object with first-class upgrade and rollback semantics rather than something you tear down and recreate.

A GOOD ANSWER COVERS To upgrade, run helm upgrade myapp ./chart with any new --set or -f overrides, optionally pinning a new chart version with --version. Each successful upgrade produces a new revision recorded in release history. Add --wait to block until resources are ready and --atomic so that if the upgrade fails or times out, Helm automatically rolls back to the last working revision; --timeout bounds how long it waits. To inspect history, run helm history myapp, which lists revision numbers, status, and the chart and app versions. To roll back manually, run helm rollback myapp 3 to return to revision 3, or omit the number to go to the immediately previous one; this itself creates a new revision rather than deleting history. You can preview changes with helm diff if the plugin is installed.

COMMON WRONG ANSWERS Uninstalling and reinstalling the release, hand-editing the live Deployment with kubectl, forgetting --atomic or --wait so failures leave a broken state, or assuming rollback erases revisions.

LIKELY FOLLOW-UPS What does --atomic do exactly? How is a revision stored? What happens to data and PVCs on rollback? How do hooks interact with upgrades?

ONE CONCRETE EXAMPLE You deploy v2 with helm upgrade api ./chart --set image.tag=2.0 --atomic --wait. The new pods crash-loop and fail readiness within the timeout, so --atomic triggers an automatic rollback to revision 4 running v1.9. You confirm with helm history api, see revision 5 marked failed and a new revision 6 marked deployed, and the app stays healthy.