GitOps and Infrastructure

GitOps uses Git as the reviewed source of truth for desired state. It is most valuable when infrastructure and runtime configuration need audit, repeatability, and drift control.

Terraform GitOps

For Terraform, keep plans visible and applies controlled:

• Store reusable modules separately from live environment configuration.
• Split state by blast radius, ownership boundary, and environment.
• Use remote state with locking and strict access controls.
• Run formatting, validation, policy, cost, and security checks on pull requests.
• Require human approval for high-risk applies unless the organization is mature enough for fully automated applies.

Atlantis remains a common fit for pull-request-driven Terraform in self-hosted environments. Terraform Cloud, Spacelift, Env0, Scalr, and GitHub Actions based workflows are also common, depending on governance, cost, and hosting requirements.

Kubernetes GitOps

For Kubernetes, reconcile desired state into clusters:

• Keep base manifests, overlays, and environment values versioned.
• Use pull requests for application, Helm, Kustomize, and policy changes.
• Let controllers reconcile approved changes rather than granting broad cluster access to CI jobs.
• Alert on drift, reconciliation failures, and suspended resources.

Flux and Argo CD are the primary Kubernetes GitOps choices. Flux is often favored for a Kubernetes-native, controller-oriented model. Argo CD is often favored for a rich UI, application visibility, and multi-team operations.

Policy and drift

Add policy checks before apply and runtime enforcement after apply:

• Open Policy Agent, Conftest, Kyverno, ValidatingAdmissionPolicy, or Gatekeeper for Kubernetes guardrails.
• Checkov, tfsec, Terrascan, and OPA policies for Terraform changes.
• Drift detection from Terraform platforms, Argo CD, Flux, or cloud-native configuration tools.

Repository patterns

Prefer clear ownership over clever mono-repo designs. Common patterns are:

• One repository for platform modules.
• One repository per product or domain for live infrastructure.
• One cluster configuration repository per environment or platform domain.
• CODEOWNERS rules that match the operational ownership model.