Document best practices for maintaining the user-provided Helm values file and keeping it consistent over releases.

We noticed so far that people tend to copy the whole default values.yaml file from the Helm Chart, and then customize it locally. This might cause several issues:

• the user's copy of the values file might be too cluttered, making it hard to understand/understand/maintain
• if the default values file is updated later in a newer Chart version and new items get added to list fields for example, the user may get some weird behavior because the lists in their previous copy will always overwrite the corresponding list fields defined in the default values (Helm does not merge lists)

Possible recommendations for the user:

• Keep their values file(s) minimal, with only the fields that they are actually changing. No need to copy all the untouched ones from the default values file (well, except array fields that they are updating). Helm will always apply the user-specified values file on top of the chart's default values (merging maps, but overwriting lists). Otherwise, it might be tricky over time to keep up with changes that we do in the default values file.

• (Side note) It is also possible for the user to have multiple values files and they can always pass the `--values` option to Helm multiple times, and Helm will take care of merging them in the order provided, e.g.:

  helm upgrade --install my-rhdh rhdh-chart \
    --values values-base.yaml \
    --values values-prod.yaml
  

• Do not store sentitive information (passwords, API keys, tokens, ...) in the values file.

• As for the Helm limitation wrt lists, we should probably consider documenting the changes to the default values file as part of the release notes?

• (anything else?)...

Slack thread: https://redhat-internal.slack.com/archives/C06SGFD65NC/p1755698741265629?thread_ts=1755695465.974779&cid=C06SGFD65NC