<p>Helm charts should not be built for a specific environment, IMHO. You can see that many of the official helm charts have a set of default values and they are configurable from outside. You also can create a helm chart like that and declare your deployment + environment-specific values with another tool like <a href="https://github.com/fluxcd/helm-operator" rel="nofollow noreferrer">Helm Operator</a> or <a href="https://argoproj.github.io/argo-cd/" rel="nofollow noreferrer">ArgoCD</a>. In this way, you can both simplify your build pipeline and increase <a href="https://12factor.net/dev-prod-parity" rel="nofollow noreferrer">dev/prod parity</a>. You can use that one chart and <strong>promote</strong> the same build into different environments so you can be sure that different environments are identical except the configuration.</p>
<p>Example ArgoCD application manifests:</p>
<p><strong>production-application.yaml:</strong></p>
<pre><code>apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: production-yourservice
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/yourorganisation/helm-charts
    path: yourservice
    targetRevision: master
    helm:
      values: |
        environment: production
        replicas: 10
  destination:
    server: https://kubernetes.default.svc
    namespace: production-yourservice
</code></pre>
<p><strong>staging-application.yaml:</strong></p>
<pre><code>apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: staging-yourservice
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/yourorganisation/helm-charts
    path: yourservice
    targetRevision: master
    helm:
      values: |
        environment: staging
        replicas: 1
  destination:
    server: https://kubernetes.default.svc
    namespace: staging-yourservice
</code></pre>

CC BY-SA 4.0
2021-02-22T20:49:57.357Z
I personally do NOT like this solution at all since now I have to maintain multiple manifest files for multiple applications, different only in the environment they're deployed in.
Chris F
CC BY-SA 4.0
2022-03-28T20:10:59.067Z
@chris-f yes, duplicating the manifest files is not the way. You can use Helm chart of charts (I'm not a big fan) or putting together & overriding the manifest files with Kustomize, which I like to combine with ArgoCD.
David Lukac
CC BY-SA 4.0
2021-02-22T20:19:59.550Z
2021-02-22T20:19:59.550Z
yozel
<ol>
<li>You could set up the &quot;environments&quot; as <a href="https://helm.sh/docs/chart_template_guide/subcharts_and_globals/" rel="nofollow noreferrer">Chart of charts</a> using Helm</li>
<li>or (my prefered way) utilize <a href="https://argoproj.github.io/cd/" rel="nofollow noreferrer">ArgoCD</a> with <a href="https://kustomize.io/" rel="nofollow noreferrer">Kustomize</a> - having &quot;default&quot; manifest for each service, creating the &quot;environment&quot; with a Kustomize file, referencing the &quot;default&quot; manifests and overriding needed values.</li>
</ol>
<p>(also see my other answer on <a href="https://devops.stackexchange.com/a/15698/8025">how to use ArgoCD</a>)</p>

CC BY-SA 4.0
2022-03-28T14:20:17.200Z
2022-03-28T14:20:17.200Z
David Lukac
<p>I'm new to Kubernetes, and hence helm, so I've been reading a lot, and teaching myself by setting up a cluster, services, deployments, and pods. In my case I use AWS EKS.</p>
<p>I now at least understand each piece from a technical point of view. But now I want to put it all together in managing an &quot;environment.&quot; I believe this is the idea behind GitOps.</p>
<p>Say I'm a QA person and am testing a &quot;staging&quot; environment. This environment comprises a number of microservices with their own respective versions. So logically I can represent it this way</p>
<pre><code>/staging-2021-03-06-4 # 4th build of staging environment on 2/06/2021
- microservice1:1.1.0
- microservice2:1.2.0
- microservice3:1.3.0
</code></pre>
<p>When we build the next staging, e.g, <code>staging-2021-03-06-5</code>, anyone of those microservices versions can change.</p>
<p>But now I, the QA guy, find an issue with above <code>staging-2021-03-06-4</code> build, and I ask a developer to look at it. I want to be able to just tell the developer to &quot;check out&quot; the <code>staging-2021-03-06-4</code> environment so he/she can have <strong>exactly</strong> the environment that I have to reproduce the issue.</p>
<p>I'm thinking I can set up this idea of &quot;environment&quot; with <code>helm</code>, since the &quot;environment&quot; is nothing but a package of packages? Is this the correct utility of <code>helm</code>? If so, do I just set up a <code>staging-2021-03-06-4</code> helm chart that has dependencies of other charts, and those other charts are for each microservice?</p>
<p>I'm also reading <a href="https://devops.stackexchange.com/questions/6641/how-to-manage-10-team-environments-with-helm-and-kubernetes">How to manage 10+ team environments with Helm and Kubernetes?</a> since it applies to me also, but that describes a different (additional) problem I'm trying to solve with <code>helm</code>.</p>
<p><strong>Update</strong>: I think I'm essentially wanting GitOps, so I'll read up on that.</p>

CC BY-SA 4.0
2021-02-06T21:26:16.890Z
We're building a tool as a layer on top of GitOps - https://relizahub.com - with the specific functionality you're asking about described here - https://github.com/relizaio/reliza-cli#72-use-case-replace-tags-on-deployment-templates-to-inject-correct-artifacts-for-gitops-using-instance-and-revision . It's an early stage for us, so feel free to connect if this resonates.
taleodor
CC BY-SA 4.0
2021-02-07T22:20:12.890Z
@taleodor I briefly checked it out, looks very useful so far. Thanks.
Chris F
CC BY-SA 4.0
2021-02-08T14:12:12.203Z
I'm currently studying https://github.com/fluxcd/helm-operator-get-started
Chris F
CC BY-SA 4.0
2021-02-08T14:49:40.073Z
Check ArgoCD as well, i.e. we have sample helm CD based on Argo here - https://gitlab.com/taleodor/sample-helm-cd/

Also feel free to connect with me - would be happy to discuss more - https://www.linkedin.com/in/pshukhman/
taleodor
CC BY-SA 4.0
2021-02-09T18:31:38.533Z
@taleodor, I sent you a LI connection request. I do have questions.
Chris F
<kubernetes><helm><kubernetes-helm>
Using helm to manage an "environment?"
Chris F
# Using helm to manage an "environment?"

(Asked by: username_0 on 2021-02-06)

I'm new to Kubernetes, and hence helm, so I've been reading a lot, and teaching myself by setting up a cluster, services, deployments, and pods. In my case I use AWS EKS.
I now at least understand each piece from a technical point of view. But now I want to put it all together in managing an "environment." I believe this is the idea behind GitOps.
Say I'm a QA person and am testing a "staging" environment. This environment comprises a number of microservices with their own respective versions. So logically I can represent it this way
/staging-2021-03-06-4 # 4th build of staging environment on 2/06/2021
- microservice1:1.1.0
- microservice2:1.2.0
- microservice3:1.3.0

When we build the next staging, e.g, staging-2021-03-06-5, anyone of those microservices versions can change.
But now I, the QA guy, find an issue with above staging-2021-03-06-4 build, and I ask a developer to look at it. I want to be able to just tell the developer to "check out" the staging-2021-03-06-4 environment so he/she can have exactly the environment that I have to reproduce the issue.
I'm thinking I can set up this idea of "environment" with helm, since the "environment" is nothing but a package of packages? Is this the correct utility of helm? If so, do I just set up a staging-2021-03-06-4 helm chart that has dependencies of other charts, and those other charts are for each microservice?
I'm also reading How to manage 10+ team environments with Helm and Kubernetes? since it applies to me also, but that describes a different (additional) problem I'm trying to solve with helm.
Update: I think I'm essentially wanting GitOps, so I'll read up on that.

**Tags:** kubernetes, helm, kubernetes-helm

> **Comments:**
> **username_1**: We're building a tool as a layer on top of GitOps - https://relizahub.com - with the specific functionality you're asking about described here - https://github.com/relizaio/reliza-cli#72-use-case-replace-tags-on-deployment-templates-to-inject-correct-artifacts-for-gitops-using-instance-and-revision . It's an early stage for us, so feel free to connect if this resonates.  
> **username_0**: @username_1 I briefly checked it out, looks very useful so far. Thanks.  
> **username_0**: I'm currently studying https://github.com/fluxcd/helm-operator-get-started  
> **username_1**: Check ArgoCD as well, i.e. we have sample helm CD based on Argo here - https://gitlab.com/username_1/sample-helm-cd/  Also feel free to connect with me - would be happy to discuss more - https://www.linkedin.com/in/pshukhman/  
> **username_0**: @username_1, I sent you a LI connection request. I do have questions.  

---

## 2 answers

### Answer by username_2 on 2021-02-22. Score: 1

Helm charts should not be built for a specific environment, IMHO. You can see that many of the official helm charts have a set of default values and they are configurable from outside. You also can create a helm chart like that and declare your deployment + environment-specific values with another tool like Helm Operator or ArgoCD. In this way, you can both simplify your build pipeline and increase dev/prod parity. You can use that one chart and promote the same build into different environments so you can be sure that different environments are identical except the configuration.
Example ArgoCD application manifests:
production-application.yaml:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: production-yourservice
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/yourorganisation/helm-charts
    path: yourservice
    targetRevision: master
    helm:
      values: |
        environment: production
        replicas: 10
  destination:
    server: https://kubernetes.default.svc
    namespace: production-yourservice

staging-application.yaml:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: staging-yourservice
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/yourorganisation/helm-charts
    path: yourservice
    targetRevision: master
    helm:
      values: |
        environment: staging
        replicas: 1
  destination:
    server: https://kubernetes.default.svc
    namespace: staging-yourservice

> **Comments:**
> **username_0**: I personally do NOT like this solution at all since now I have to maintain multiple manifest files for multiple applications, different only in the environment they're deployed in.  
> **username_3**: @chris-f yes, duplicating the manifest files is not the way. You can use Helm chart of charts (I'm not a big fan) or putting together & overriding the manifest files with Kustomize, which I like to combine with ArgoCD.  

---

### Answer by username_3 on 2022-03-28. Score: 0

1. You could set up the "environments" as [Chart of charts](https://helm.sh/docs/chart_template_guide/subcharts_and_globals/) using Helm
2. or (my prefered way) utilize [ArgoCD](https://argoproj.github.io/cd/) with [Kustomize](https://kustomize.io/) - having "default" manifest for each service, creating the "environment" with a Kustomize file, referencing the "default" manifests and overriding needed values.

(also see my other answer on [how to use ArgoCD](https://devops.stackexchange.com/a/15698/8025))


---

