helm-release-plugin VS flux2-kustomize-helm-example

Helm temporary releases are one of the most useful features in the Helm release plugin. A temporary release allows you to run an application, while you test a new feature or validate a fix, and then it gets deleted and purged after a certain period of time. Temporary releases can be deployed in a new Kubernetes namespace or in an existing one. The temporary application is effectively isolated from the rest of the Kubernetes cluster. It only has access to the resources that are allotted to it, and it iss are not affected by other pods, or the rest of the cluster. When you use a temporary environment to run the application, it is not impacting other apps running in the cluster. This means that they: Have their own set of persistent volumes, have their own set of APIs (endpoints, certificates, and so on). You’ll find that temporary environments are very useful for testing, staging, and debugging, since you can use them to run test pods without disturbing the rest of the Kubernetes cluster, and not worry about forgotten releases that keep consuming cloud resources, and keep spending your cloud budget.

Any public repo show-casing a nice structure? (I am used to the Gitops world on K8s, and for the case of FluxCD for instance I would recommend this repo as a good practice to start multi-tenancy. https://github.com/fluxcd/flux2-kustomize-helm-example. I am looking for a similar "boilerplate" but for TF 😅)

My recommendation would be to take a look at their documented example of this exact scenario with various overlays for production and staging, but you could ofc add as many as you wanted. All you would do is for production point flux to the production overlay/ directory, which then calls all your normal files but overrides some values you desire. Further to this you can keep your helm chart focused on lets say the "most-common" use case, then just call it with whatever additional values you would like, E.G here in the same repo as above. Notice the values at the bottom of the yaml file which override the charts default values.

Here's an example using flux v2 to deploy to multiple environments/clusters: https://github.com/fluxcd/flux2-kustomize-helm-example

We are using flux2, which uses Kustomize under the hood. It takes a little bit of time to learn about the different CRD's which are available but once you do it works excellent. They also have an example project which sounds like it might fit your use case https://github.com/fluxcd/flux2-kustomize-helm-example

As /u/vincentdesmet mentioned Kustomize will most likely to solve your many "apps" with slightly difference issue, this is a good example https://github.com/fluxcd/flux2-kustomize-helm-example (also include helm one)