GitOps for Application Environments: CNPA practice questions

Once a platform runs more than one environment, the GitOps question becomes how to describe several variants of the same application and how to move a change from one environment to the next. The answers are mostly about repository layout and promotion.

Flux's guide to structuring repositories describes the main options. In a monorepo, all Kubernetes manifests live in one repository, with the environment-specific configuration on the same branch, typically main. A common layout has shared bases and per-environment overlays, for example apps/base, apps/staging and apps/production, plus a clusters directory where each cluster's state references the app and infrastructure overlays it should run. Separating apps from infrastructure lets a cluster reconcile add-ons and controllers before the applications that depend on them. In a repo-per-environment layout production gets its own repository; because Git cannot restrict read access to individual files, a separate repository gives tighter control over who sees production configuration, at the cost of more work when promoting changes. The guide also describes repo-per-team and repo-per-app variants. Branches other than main stay short-lived and are deleted once their pull request merges, in line with trunk-based development.

Kustomize provides the overlay mechanism. A base is a directory with a kustomization.yaml containing a set of resources and customizations; an overlay refers to a base and changes what differs, such as replica counts, resource limits, hostnames or image tags, so most YAML is written once. Helm reaches the same result with one chart and a values file per environment.

Promotion is a change to Git. Flux's guidance shows new application releases delivered automatically to staging through image updates to Git, while version bumps for production are pushed to a new branch so that someone can open and approve a pull request. Infrastructure changes can be more disruptive, so the guide suggests merging them to staging first and promoting them to production only after the staging cluster has reconciled and passed conformance tests, with the promotion gated by pull request reviews and end-to-end tests. Flagger canary releases can limit the impact of a problem that escapes staging.

When many clusters need the same application, Argo CD's ApplicationSet controller generates Applications from a single template. Its list generator uses a literal list of clusters, the cluster generator uses the clusters defined in Argo CD, the Git generator derives parameters from files or directories in a repository, and the matrix generator combines two generators. It also improves self-service in multitenant clusters, letting tenants deploy without a cluster administrator enabling each destination, although the documentation asks readers to understand the security implications first.

Misconceptions: one long-lived branch per environment is not a GitOps requirement, copying complete manifests for each environment is unnecessary, and promotion should never mean rebuilding the image for production.

At associate level, expect questions about choosing a repository layout, using overlays for environment differences, gating promotion to production, and generating per-cluster deployments from one definition.