Managing Environments

Same chart, different values

The core rule: one chart, many values files. The chart is built and versioned once; each environment is a set of values plus a target cluster and namespace. A common layout keeps values.yaml defaults in the chart and environment files beside the deployment configuration: values-common.yaml, values-staging.yaml, values-prod.yaml, passed in that order so later files override earlier ones. Promote the same chart version and image tag from staging to production rather than rebuilding. Helmfile is a popular declarative tool that lists releases, chart versions and values per environment in one helmfile.yaml and applies them with helmfile apply, adding diff and ordering on top of Helm. Whatever tool you use, the goal is that the full desired state of each environment lives in Git.

One chart promoted through environments

The chart and image stay the same; only the values layered on top change per environment.

A helmfile for two environments

helmfile -e prod diff previews, helmfile -e prod apply applies.

environments:
  staging:
    values: [env/staging.yaml]
  prod:
    values: [env/prod.yaml]
---
releases:
  - name: shop-api
    namespace: shop
    chart: oci://ghcr.io/acme/charts/shop-api
    version: 1.4.0
    values:
      - values/shop-api/common.yaml
      - values/shop-api/{{ .Environment.Name }}.yaml
    set:
      - name: image.tag
        value: {{ .Values.shopApiImageTag | quote }}

Avoid --reuse-values in pipelines

--reuse-values takes the previous release's values and merges your new flags on top, so values that were set by hand months ago live on invisibly, and new chart defaults are ignored. Pass the complete set of values files on every upgrade instead.

त्वरित जाँच: What should change when promoting a release from staging to production?

• Only the environment-specific values and target cluster
• The chart version and the image, rebuilt for production
• The chart's templates
• Nothing; production uses staging's cluster