Git, CI/CD & GitOpsCV · GitOps Anti-PatternsSynthesis
The GitOps discipline — the synthesis
What you'll learn
- Combine the five anti-patterns and their fixes into a single architecture
- Distinguish the GitOps discipline from a list of GitOps tools
- Apply the discipline to a greenfield GitOps rollout and to a retrofit of an existing platform
- Recognise the trade-offs the discipline imposes and the cases where pragmatism overrides the discipline
Prerequisites
Verified against Git 2.55.x teaching target; 2.40+ minimum · GitHub Actions continuous service; Aug 2026 documentation baseline · Argo CD v3.5.x teaching target; v3.0+ minimum · Flux v2.9.x · Sigstore Cosign v3.1.x · SLSA v1.2 · OCI Distribution Specification v1.1 · Git LFS v3.7.1 · Kubernetes (cross-course target) 1.36.x
GitOps is a discipline. The discipline is the consistent application of a small number of choices across every controller, repository, cluster, and promotion. A team that has chosen cluster-admin, prune without diffs, plaintext secrets, no self-heal, and a single repo has adopted the controller and abandoned the discipline.
The five choices as one architecture
The five anti-patterns in this part and their fixes compose.
flowchart TB
subgraph Controller
A1["Scoped ServiceAccount per project"] --> A2["Per-cluster controllers"]
A2 --> A3["AppProject with sourceRepos and destinations"]
end
subgraph Sync
B1["Dry-run diff paired with sync"] --> B2["Sandbox for first prune"]
B2 --> B3["Prune=false override for hotfix"]
end
subgraph Secrets
C1["No plaintext in repo"] --> C2["Sealed Secrets or SOPS or External Secrets"]
C2 --> C3["Pre-commit, CI, forge scanning"]
end
subgraph Drift
D1["Self-heal enabled"] --> D2["IgnoreDifferences for legitimate fields"]
D2 --> D3["Reconciliation budget alert"]
end
subgraph Promotion
E1["Per-environment AppProject"] --> E2["Per-cluster controllers"]
E2 --> E3["Promotion-by-ref with reviewable PR"]
end
Controller --> Sync
Sync --> Secrets
Secrets --> Drift
Drift --> Promotion
Promotion --> Controller
The architecture has five components and four seams:
- Controller and Sync. A cluster-admin controller applied to a prune-enabled Application with no diff is a controller that can delete any resource in any cluster.
- Sync and Secrets. A controller that holds the SOPS key on a cluster-admin ServiceAccount is a controller whose key compromise is a secret compromise.
- Secrets and Drift. A controller that decrypts a secret but does not self-heal reports the divergence but does not reconcile.
- Drift and Promotion. A controller that self-heals production against a single-repo source promotes every change to production.
The discipline, not the tools
The discipline is independent of the controller. Argo CD, Flux, and the OpenGitOps standards implement the same discipline.
The discipline has four properties that any implementation must satisfy:
- The repository is the source of truth.
- The controller reconciles the cluster to the repository. Self-heal is the default.
- The controller’s privilege is the minimum the manifests require.
- The promotion flow crosses each environment boundary explicitly.
A controller that does not satisfy all four is a sync engine with a privilege boundary the team has not tested.
The retrofit path
A team adopting the discipline on an existing platform faces the cost of every fix in this part.
flowchart LR
A["Inventory the current state"] --> B["Encrypt or reference the secrets"]
B --> C["Scope the controllers per project"]
C --> D["Enable diffs and sandboxes for prune"]
D --> E["Enable self-heal with IgnoreDifferences"]
E --> F["Adopt promotion-by-ref"]
F --> G["Run a reconciliation budget"]
The order is deliberate. Inventory first. Secrets second.
Each step has a transition window. The team operates the old and new in parallel.
The trade-offs
The discipline imposes four costs:
- Operational complexity. Per-environment AppProjects, per-cluster controllers, promotion-by-ref.
- Promoter latency. Promotion-by-ref is slower.
- Tool discipline. Pre-commit hooks, CI scans, drift alerts.
- Vendor lock-in by principle.
The trade-offs are not avoidable. Each case of pragmatism overriding the discipline is logged and reviewed.
Production discipline
- The five choices are made together.
- The discipline outlives the controller.
- The retrofit is incremental.
- Pragmatism is logged.
Cross-course references
- This course, Part CI (GitOpsAnti-patterns) - the five anti-patterns.
- This course, Part CXVI (Governance) - the review process.
Quiz
Knowledge check · 4 questions
Q1. A team has scoped the controller per project, enabled self-heal with IgnoreDifferences, encrypted secrets with SOPS, and adopted per-cluster controllers. They have not enabled dry-run diffs for prune-enabled syncs. What is the residual risk?
Q2. GitOps is a tool choice; adopting Argo CD or Flux is the same as adopting GitOps.
Q3. Name the four properties any GitOps controller must satisfy to be a GitOps controller.
Q4. Recommend the discipline for a greenfield GitOps rollout and identify the seams that fail if any one choice is skipped.
A platform team is launching a greenfield GitOps rollout. They have chosen Argo CD for the staging cluster and Flux for the production cluster because the two teams have different operational preferences. They want to know what the GitOps discipline requires of them regardless of the controller, and where the seams between the five choices will fail if any one is skipped.
Passing score: 75%. Answers are checked in this browser.