Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2021-02-22T20:49:57.357Z
Answers: 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.
Answers: Chris F
Answers: CC BY-SA 4.0
Answers: 2022-03-28T20:10:59.067Z
Answers: @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.
Answers: David Lukac
Answers: CC BY-SA 4.0
Answers: 2021-02-22T20:19:59.550Z
Answers: 2021-02-22T20:19:59.550Z
Answers: yozel
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2022-03-28T14:20:17.200Z
Answers: 2022-03-28T14:20:17.200Z
Answers: David Lukac
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2021-02-06T21:26:16.890Z
Comments: 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.
Comments: taleodor
Comments: CC BY-SA 4.0
Comments: 2021-02-07T22:20:12.890Z
Comments: @taleodor I briefly checked it out, looks very useful so far. Thanks.
Comments: Chris F
Comments: CC BY-SA 4.0
Comments: 2021-02-08T14:12:12.203Z
Comments: I'm currently studying https://github.com/fluxcd/helm-operator-get-started
Comments: Chris F
Comments: CC BY-SA 4.0
Comments: 2021-02-08T14:49:40.073Z
Comments: 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/
Comments: taleodor
Comments: CC BY-SA 4.0
Comments: 2021-02-09T18:31:38.533Z
Comments: @taleodor, I sent you a LI connection request. I do have questions.
Comments: Chris F
Tags: <kubernetes><helm><kubernetes-helm>
Title: Using helm to manage an "environment?"
UserDisplayName: Chris F
ThreadText: # 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?](https://devops.stackexchange.com/questions/6641/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](https://github.com/fluxcd/helm-operator) or [ArgoCD](https://argoproj.github.io/argo-cd/). In this way, you can both simplify your build pipeline and increase [dev/prod parity](https://12factor.net/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**: @username_0-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))
  
  
  ---
  
  