09 — Base values + per-env overrides (dev / staging / prod)
Note — different shape than other examples. Every other folder under
docs/02-examples/ships a singlevalues.yamland follows the fixedNN-name/{values.yaml,argocd/,flux/,helm/}layout. This example deliberately departs from that — there is novalues.yaml. Tooling that iteratesdocs/02-examples/*/values.yamlwill skip this folder, which is intentional. Usevalues-base.yamltogether with one of thevalues-<env>.yamloverlays.
One chart, one app — three environments. The values are split into a values-base.yaml carrying the invariant configuration and three thin values-<env>.yaml overlays that adjust replica counts, resource sizing, image tags and a few env vars.
This shows how the chart’s keyed-map structure (ADR 002) and global.env cascade (ADR 003) make per-environment overlays minimal — typically 10-20 lines each.
Files (different shape than other examples)
| File | Purpose |
|---|---|
values-base.yaml | Common configuration applied to every environment. |
values-dev.yaml | Dev overrides: 1 replica, smaller resources, dev image tag. |
values-staging.yaml | Staging overrides: 2 replicas, prod-ish sizing, staging hostname. |
values-prod.yaml | Prod overrides: HPA on, real resources, real hostname, monitoring on. |
argocd/application-prod.yaml | Argo CD Application for prod, multi-source: chart + base + prod overlay. |
argocd/applicationset.yaml | One Argo CD ApplicationSet rendering one Application per environment from a list generator. |
flux/ocirepository.yaml | Flux OCIRepository. |
flux/helmrelease-prod.yaml | Flux HelmRelease for prod, with valuesFrom referencing a ConfigMap + inline overlay. |
helm/install-dev.sh | Plain helm upgrade --install for dev (-f values-base.yaml -f values-dev.yaml). |
What this shows
- Two-file values pattern: pass
values-base.yamlandvalues-<env>.yamlto Helm via repeated-f. Later files win on key collision. - Per-env
fullnameOverride: each overlay pins its own resource-name prefix (orders-dev/orders-staging/orders-prod), so the prod Ingress backend can nameorders-prod-apiwithout depending on the release name Argo CD or Flux passes. - Argo CD multi-source with multiple
valueFiles: the chart source lists both files; Argo CD merges them in order before running Helm. - Argo CD
ApplicationSet: a list generator declares the envs once; the template stamps out an Application per env. Avoids hand-maintaining three near-identical Application CRs. - Flux
valuesFrom: prod values can also live in a ConfigMap (managed separately) — useful when ops change values out-of-band of git.
Try it (dev only — adjust for other envs)
# Helm
bash helm/install-dev.sh
# Argo CD (prod)
kubectl apply -f argocd/application-prod.yaml -n argocd
# Argo CD (all three envs at once)
kubectl apply -f argocd/applicationset.yaml -n argocd
# Flux (prod)
kubectl apply -f flux/