How would you standardise what a `helm upgrade` starts from across many teams and pipelines?

### Frame it as a source-of-truth question Every `helm upgrade` starts from something. Either it starts from a file in your repository, or it starts from the values recorded on the previous revision. Those are two different sources of truth, and an organisation that has not chosen one ends up with both. The flags — the default, `--reset-values`, `--reuse-values`, `--reset-then-reuse-values` — are just how each team happens to express its unstated choice, which is why the argument keeps recurring at the level of syntax when it is really about ownership. ### The case for file-driven, always When every upgrade passes the complete values file, four properties come free. Reproducibility: any engineer can recreate the release from the repository alone, on a new cluster, in a disaster. Reviewability: a configuration change is a diff a human approved, not a flag someone typed at 02:00. Determinism: the same commit plus the same chart version yields the same render, so promotion between environments means comparing files rather than comparing clusters. And upgradability: new chart versions actually deliver their new defaults, instead of being masked by defaults that an earlier reuse run promoted into overrides. The cost is real and worth naming. Someone has to keep the file complete, including the parts an operator once fixed by hand. Emergency changes are slower, because the fast path is a pull request. Teams with a chart that is difficult to configure will feel that cost first, and will route around it with `--set` unless you make the fast path acceptable. ### The case for allowing reuse, honestly stated Reuse exists because operators are sometimes handed a release without its file: an inherited estate, a chart installed years ago, a vendor's install instructions that were a single command line. In that world `--reset-then-reuse-values` is genuinely the safest thing available, because the alternative — guessing at a file — risks reverting settings nobody remembers. Recognising this is the difference between a policy people follow and a policy people bypass silently. What I would not accept is reuse inside automation. A pipeline that upgrades with `--reuse-values` has made the release record the authority, and that record is not reviewable, not diffable in a pull request, and grows a layer of stale chart defaults with every run. It also fails the disaster test: if the namespace is lost, the configuration is lost with it. ### The standard I would set * **Automation** passes the complete values file and states `--reset-values` explicitly, so a reader of the pipeline sees the intent rather than inferring it from the absence of a flag. * **Interactive work** may use `--reset-then-reuse-values`, never `--reuse-values`, and owes a follow-up change that reconciles the file. Give that follow-up a ticket, not a promise. * **Bare `--set` in production** is the one thing I would treat as an incident-only action, because it silently narrows the override set on releases whose pipeline is not yet file-driven, and because it leaves no artefact anyone can review. * **Onboarding a legacy release** has a documented path: capture the stored values, prune the entries that merely restate chart defaults, verify by comparing rendered output, commit, and switch that release to the file-driven path. ### Make it detectable, not just forbidden A rule nobody can check is a preference. Two cheap controls make this one real. First, a scheduled job that reads each release's stored user-supplied values and compares them with the committed file, reporting differences as drift — this catches the out-of-band `--set` weeks before the next full-file deploy "reverts" it and causes the outage. Second, a rendered-manifest comparison in the promotion path: render the candidate and compare against the manifests the current revision was created from, so an unexpected diff blocks the change rather than surprising it. Where releases are driven by a controller reconciling from a repository, this question largely dissolves, because every apply supplies the full set by construction — which is itself an argument for that model when a team is choosing. ### How I would decide, and what I would concede I would set the file-driven default centrally, allow per-team exceptions with an owner and an expiry, and measure adoption by the drift report rather than by policy documents. I would concede the emergency path explicitly, because pretending it does not exist is how organisations end up with undocumented reuse everywhere. The goal is not flag purity: it is that at any moment, someone can answer "what is this release configured with, and where is that written down" without reading a cluster.