Comment by LunicLynx

We do rendered manifest pattern. The chart gets rendered into a single yaml, that get checked into it's own branch and PR. That way, any changes can be easily inspected before merging and can work with confidence that e.g. changing a setting or updating isn't going to change ALL of the objects. It's also extremely easy to (trustingly) roll back to previous states.

The only downside is that you can't really prune excess objects with this method. We're pushed to use Argo for deployment which I don't really gel with, but I trust it to apply the yaml, and at the very least it highlights when objects need to be removed.

Honestly my take on Helm charts is to keep them as simple as possible. All the complicated stuff you see in public charts people publish? Yeah stay far, far away from that. Our Helm charts at my job are 95% plain YAML files with an occasional variable insertion to handle cases where you need different hostnames (etc) based on the environment being deployed to. They are a pleasure to work with because they are so simple.

Even some of the examples in TFA (like the optional persistent storage one) are IMO way more complex than what you should use Helm for. At that point you're better off using a programming language to generate the YAML based on some kind of state object you create. It's way too error prone to do that stuff with YAML templating imo.

I also get uneasy feeling, that the "values.yaml" section, it feels often underspecified and a black-box.

I wish timoni[1] would take off.

It’s based on Cue and doesn’t rely on templating.

[1] timoni.sh