ADR-0016: Per-environment Helm chart versioning (values_v2 vs values_v3)

Status: Accepted Category: INFRA Date decided: During the multi-zone initiative Date documented: 2026-05-13

Context

Production was the first (and so far only) environment where Meesho rolled out multi-zone deployments — running services in two GCP zones in parallel with split-deploy and per-service-type validation (see ADR-0013). Multi-zone awareness required a new shape of Helm chart values: per-zone overlay files (gcp-ase1a-values.yaml, etc.), service-type metadata, and additional tuning. Lower environments (stg, int, ftr) do not run multi-zone today and have no plan to. Forcing them onto the multi-zone-shaped chart would either require multi-zone setup they don't have, or carry chart fields they never use.

Decision

constructParam.groovy picks the Helm chart values path per environment: helmChartsPath = (env == 'prd') ? 'values_v3' : 'values_v2'. Production reads from values_v3/ in devops-helm-charts (multi-zone-aware); every other environment reads from values_v2/ (single-zone). Both versions are actively maintained — values_v2 is the live chart for non-prod, not a deprecated legacy path.

Alternatives Considered

No alternatives were explicitly evaluated by the team during this interview. A unified chart that handles both single-zone and multi-zone via conditional logic was the obvious counter-proposal but was not taken; the team kept the two versions side-by-side instead.

Consequences

Positive:

Non-prod chart stays simple — no multi-zone-only fields polluting the values tree for engineers and reviewers who don't need them.
Multi-zone schema can evolve in values_v3 without coordinating breaking changes against non-prod chart consumers.
Production deploys exercise a chart shape that matches production's runtime topology exactly; no "unused config" surface.

Negative:

A service that exists in prd has its values defined in two places (values_v2/<bu>/.../values.yaml and values_v3/<bu>/.../values.yaml); a config change relevant to both has to land in both, and drift between them is silent.
Engineers debugging an issue have to know which version their environment uses before they can find the right file.

Neutral:

The decision lives in one line of constructParam.groovy; flipping a new env onto values_v3 is trivial when its multi-zone story is ready.

Constraints

Multi-zone requires per-zone overlay files and service-type validation that values_v2 does not have.
Non-prod environments do not run multi-zone and have no roadmap to; the v3 shape would carry dead configuration there.

Current Assessment

Adequate with caveats — splitting by environment maps cleanly to the runtime topology, but the dual maintenance burden grows linearly with active services and is invisible to anyone not in the DevOps loop. Worth revisiting if/when non-prod gains multi-zone.

ADR-0013: Multi-zone deployables gated out of direct Jenkins ArgoCD — the multi-zone initiative that drove the values_v3 rollout.
ADR-0007: GitOps Deployments via Strict 4-Step ArgoCD Sync Sequence — the deploy mechanism that consumes whichever chart values path is selected here.

Notes

Key files: src/com/meesho/utilities/constructParam.groovy
Chart source: https://github.com/Meesho/devops-helm-charts — values_v2/ and values_v3/ are sibling top-level directories.
Discovery id: INFRA-1

3.8 KiB Raw Blame History