Digital TransformationIntermediate7 min read

GitOps Practice

GitOps is the practice of using Git as the single source of truth for infrastructure and application deployments — the desired state of every system is described declaratively in Git, and a controller (Argo CD, Flux) continuously reconciles the actual cluster state to match the Git state. Coined by Weaveworks in 2017 and popularized through Argo CD (now CNCF graduated, dominant in the market) and Flux (also CNCF graduated, IBM/RedHat-aligned), GitOps shifts deployment from imperative push (CI server runs kubectl apply) to declarative pull (cluster controller syncs from Git). The key promises: deployments are auditable (Git history), reversible (git revert reverts production), reproducible (same Git commit produces same cluster state), and secure (no CI credentials in clusters). The KnowMBA POV: GitOps without ownership of the rendered manifests is theater. Many organizations adopt Argo CD, point it at a Helm chart they don't fully understand, and declare GitOps achieved — but if no human reviews the actual rendered Kubernetes manifests, you've just moved the imperative complexity into Helm templates and lost the reviewability that was the entire point.

Also known asGitOpsArgo CD PracticeFlux PracticeDeclarative DeploymentsPull-Based Continuous Delivery

Challenge a friend Browse library

The Trap

The trap is treating GitOps as a tool installation rather than a discipline. Argo CD or Flux can be installed in an afternoon; the practice of GitOps takes 12-18 months to mature. Common failure patterns: (a) Teams point GitOps controllers at Helm charts with hundreds of templated values — the rendered manifests are never reviewed, defeating the auditability promise. (b) Hot-fixes happen via kubectl apply directly to the cluster, drift from Git accumulates, and the controller fights with humans. (c) Secrets management becomes a mess (Git is not for secrets), with various half-solutions (Sealed Secrets, External Secrets Operator, SOPS) creating complexity teams underestimate. (d) Multi-environment promotion (dev → staging → prod) is bolted on without strategy, leading to either insufficient promotion gates or dramatic process overhead. (e) Application teams don't actually use the GitOps workflow — they file pull requests against a manifest repo they don't understand, and platform engineers approve everything. The deeper trap: declaring GitOps success based on tool deployment, not based on whether deployments are actually more auditable, reversible, and reliable than before.

What to Do

Six moves. (1) Decide your repository topology FIRST: monorepo for all manifests, repo-per-team, or repo-per-environment. Each has tradeoffs and changing later is painful. (2) Choose Argo CD or Flux based on team preference (Argo CD has a stronger UI and ApplicationSets pattern; Flux has a more Kubernetes-native API and stronger multi-tenancy primitives). Avoid running both. (3) Decide on Helm vs Kustomize vs raw manifests vs cdk8s — each has different tradeoffs for templating complexity vs reviewability. Most mature GitOps shops use Kustomize (simpler, more reviewable) over Helm (more powerful, less reviewable) for in-house apps. (4) Solve secrets explicitly with one approach and stick to it: External Secrets Operator (ESO) pulling from a real secrets store (Vault, AWS Secrets Manager, GCP Secret Manager) is the modern default. (5) Design promotion flow with explicit gates — environments are branches OR directories, with PR-based promotion through a defined sequence. (6) Train application teams on the workflow with real ownership — they need to read manifests, write PRs, and understand drift, not just hand off to platform engineers.

Formula

GitOps Maturity ≈ (Manifests Reviewed in PR × Drift Detection Coverage × Time to Rollback × Secrets Discipline) ÷ (Helm Template Complexity × Number of Out-of-Band kubectl Operations)

In Practice

Argo CD launched at Intuit in 2018 and became open-source / CNCF in 2020. By 2023-2024, Argo CD was dominant in enterprise GitOps adoption — CNCF surveys consistently rank it as the most-used GitOps tool, with Flux as the second largest. Intuit's own deployment of Argo CD scaled to manage thousands of applications across hundreds of clusters, becoming the reference case for large-scale GitOps. Adobe, BMW, and Tesla have published case studies on Argo CD scaling. The pattern across mature adoption: organizations that paired Argo CD with strong manifest discipline (limited Helm complexity, explicit promotion flow, secrets via ESO) reported significant deployment velocity and reliability gains. Organizations that treated Argo CD as a deployment tool without the surrounding discipline reported the inverse — manifest drift, unreviewable Helm charts, and 'why is my deployment not syncing' as the dominant Slack question. The technology delivered when the practice matured around it.

Pro Tips

01
If you can't read the rendered Kubernetes manifest in your PR, you don't have GitOps — you have Helm. Argo CD's UI shows the rendered manifest diff; require reviewers to actually look at it. The single most valuable GitOps discipline is manifest reviewability, and Helm's templating actively undermines it. Many mature GitOps shops use Helm only for third-party charts and Kustomize (or plain manifests) for everything in-house.
02
Secrets are the #1 unsolved problem in most GitOps adoptions. Git is not a place for secrets, but every tutorial pretends this is solved. Pick one approach early: External Secrets Operator (ESO) syncing from Vault/AWS SM/GCP SM is the modern default and worth the learning curve. Sealed Secrets (Bitnami) works but is awkward for rotation. SOPS works but adds local-tooling complexity. The wrong answer is 'we'll figure it out later' — secrets debt accumulates.
03
Drift detection is the GitOps health metric. Argo CD's auto-sync and drift alerts surface when humans have made changes outside Git. Track 'percentage of clusters in sync' as a KPI. A drift rate above 5-10% means your team isn't actually practicing GitOps — they're using kubectl directly. Either tighten controls or accept that the discipline isn't there yet.

Myth vs Reality

Myth

“Installing Argo CD or Flux means you're doing GitOps”

Reality

Tool installation is the smallest part of GitOps adoption. The discipline is repository structure, manifest reviewability, drift management, secrets handling, and promotion flow. Organizations that install Argo CD without these disciplines often have worse deployment hygiene than before — the tool surfaces problems but doesn't solve them.

Myth

“GitOps eliminates the need for CI”

Reality

GitOps replaces the CD (continuous deployment) part of CI/CD with pull-based reconciliation, but the CI part (build, test, image generation) still happens in traditional CI. The handoff is: CI builds an image and updates a manifest in Git; GitOps controller reconciles the cluster to match. Confusing GitOps with 'no CI' leads to confusion about where build pipelines live.

Try it

Run the numbers.

Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.

🧪

Knowledge Check

Your platform team installed Argo CD 6 months ago. Application teams now file PRs against a manifest repo containing 200+ Helm chart references with thousands of templated values. No one reviews the rendered manifests; reviewers approve based on the values.yaml diff. The platform team is proud of the 'GitOps adoption.' What's the gap?

Industry benchmarks

Is your number good?

Calibrate against real-world tiers. Use these ranges as targets — not absolutes.

GitOps Tool Adoption (CNCF Survey 2023-2024)

Cloud-native organizations using GitOps in production

Argo CD (dominant)

~50-60% of GitOps adopters

Flux

~25-35%

Other (Jenkins X, Spinnaker GitOps mode, custom)

~10-20%

Source: Hypothetical: composite from CNCF Annual Surveys

Manifest Drift Rate (Cluster Out-of-Sync %)

% of GitOps-managed clusters where actual state differs from Git

Mature Practice

< 3%

Healthy

3-8%

Adoption Gap

8-15%

Practice Not Established

> 15%

Source: Hypothetical: composite from Argo CD operator reports

Real-world cases

Companies that lived this.

Verified narratives with the numbers that prove (or break) the concept.

🌿

Intuit (Argo CD Origin)

2018-Present

success

Argo CD was created at Intuit starting in 2018 to manage their growing Kubernetes deployments at scale. By 2020, Argo CD was open-sourced and donated to CNCF, where it joined as an incubating project (graduated 2022). At Intuit's own scale, Argo CD eventually managed thousands of applications across hundreds of clusters supporting QuickBooks, TurboTax, Mint, and other Intuit products. The platform team published widely on the patterns: ApplicationSets for managing fleets of applications, app-of-apps patterns for hierarchical configuration, multi-cluster federation. Intuit's deployment became the reference case for large-scale GitOps and helped establish patterns that CNCF community subsequently formalized. Argo CD itself became dominant in the GitOps tooling market — by 2023-2024, surveys consistently ranked it as the most-deployed GitOps controller.

Origin

Intuit, 2018

CNCF Status

Graduated (2022)

Intuit Scale

Thousands of apps, hundreds of clusters

Market Position (2024)

Dominant GitOps controller

GitOps tooling matured from internal-Intuit-tool to CNCF standard in roughly 4 years — but tool maturity ran ahead of practice maturity in the broader market. Many organizations adopted Argo CD without the deployment patterns, manifest discipline, and operational practices that made it work at Intuit's scale.

Source ↗

🔗

Weaveworks (Origin of GitOps Term)

2017-2024

mixed

Weaveworks coined the term 'GitOps' in a 2017 blog post and pioneered the concept through their Flux project. Flux became one of the two dominant GitOps controllers (with Argo CD), graduating from CNCF in 2022. Weaveworks itself, despite originating the GitOps category, struggled commercially and announced wind-down in early 2024 — partially because the open-source projects (Flux, Argo CD) became standards while commercial value capture proved difficult. The intellectual contribution was significant: the GitOps principles (declarative descriptions, version-controlled state, automated reconciliation, continuous monitoring) became how a generation of platform engineers think about deployment.

GitOps Term Coined

2017 (Weaveworks blog post)

Flux CNCF Graduation

2022

Weaveworks Wind-Down

Announced 2024

Lasting Impact

GitOps principles became industry standard

Pioneering a category does not guarantee commercial success when the underlying primitives are open-source. Weaveworks gave the industry GitOps but couldn't capture commensurate commercial value. The lesson for adopters: GitOps tooling is healthy precisely because its core (controllers, manifests, Git) is open and competitive — the discipline is more valuable than any single vendor relationship.

Source ↗

Related concepts