<p>I have a project that contains the deployment descriptor files for Kubernetes. This project has a folder structure that looks like this:</p>
<pre><code>&gt; project-deployment
&gt;  - base
&gt;  - dev
&gt;  - production
</code></pre>
<p>Inside the base folder, I have the kubernetes deployment files (deployment, service, namespaces etc.,). In the dev and production folder, I have kustomization.yaml that composes everything from the base folder. So far so good. I now want to introduce helm into this so that I can manage my releases much better. My question now is how do I go about structuring my folder structure?</p>
<p>Should I move everything (base, dev and production) folder into templates and just have one Charts.yaml and values.yaml? Any thoughts?</p>

joesan
<p>The configuration values that you push into your charts should be separate between environments. Build simple extendable charts that can have overrides per environment.
For example, a good workflow would have different value files per environment with specific differences in configuration:</p>
<pre><code>~/myapp
└── config
├── production.yml
└── staging.yml
</code></pre>
<p>There are tools that can help you manage that particular use case. For example, consider using <a href="https://github.com/nuvo/orca" rel="nofollow noreferrer">orca</a>:</p>
<blockquote>
<p>What Orca does best is manage environments. An Environment is a
Kubernetes namespace with a set of Helm charts installed on it. There
are a few use cases you will probably find useful right off the bat.</p>
</blockquote>
<p>There are also some <a href="https://github.com/nuvo/orca/tree/master/docs/examples" rel="nofollow noreferrer">examples</a> provided with it.</p>
<p>I also recommend going through the official <a href="https://helm.sh/docs/chart_best_practices/" rel="nofollow noreferrer">The Chart Best Practices Guide</a>.</p>
