Originally published on kuryzhev.cloud

A solid Helm rollback strategy is usually missing the night a chart upgrade reaches production and the pods start crash-looping. Picture a typical case. The chart was upgraded in staging, and the team copied a few overrides across. The production command then ran with --reuse-values because it "keeps what is already there". The new chart version expects a key that production's stored values never had. Rendering either fails outright or, worse, succeeds with an empty string where a database mode should be.

Failure scenario: a promotion that rolls back to the wrong thing

Consider a service chart moving from 1.8 to 1.9. Version 1.9 adds database.sslMode with a sensible default and renames ingress.class to ingress.className . Staging was upgraded from a values file in Git and works.…