🤔 GitOps Has Been Hyped for Years — Why Have Only 40% Actually Adopted It?

This article was last updated on: June 29, 2026 pm

Introduction

A few days ago I was venting with a colleague who said: “We’ve been chanting GitOps for two years, we’ve built CI/CD pipelines, we’ve put K8s YAML in Git repos, but honestly — whenever something breaks in production, we just kubectl edit it directly. Then we forget to sync it back, and the next deployment overwrites the config, and alerts explode again…”

Sound familiar? 👻

Last year’s survey from The New Stack confirmed this: only about 40% of organizations have truly achieved declarative desired-state management. The concept gets plenty of airtime, but in practice there’s a widespread GitOps Gap.

Today I’ll share my company’s journey with GitOps (or more accurately, “the series of pitfalls I’ve personally stepped in”), and talk about what GitOps really looks like — how elegant the theory is, how harsh the reality is, and what practices actually work.

What Exactly Is GitOps?

Put simply: GitOps = Git repo as the single source of truth + declarative configuration + automated reconciliation engine.

Here’s my go-to analogy: the Git repo is your home’s renovation blueprint, the Kubernetes cluster is your actual house, and Argo CD (or Flux) is the diligent contractor — every few minutes it glances at the blueprint, and the moment it notices the actual renovation doesn’t match the blueprint, it fixes it without question.

│ 📝Notes: GitOps isn’t just a CI/CD approach — it’s an operational model whose core is continuous reconciliation, not continuous deployment.

The three pillars of GitOps:

Declarative configuration: You state “what I want,” not “how to do it”
Version control: All changes must go through Git, creating a complete audit trail
Automated remediation: Configuration drifted? Automatically pull it back

According to Red Hat’s official definition (reference [1]), GitOps extends DevOps and IaC principles by turning the Git repo into the “single source of truth” for cluster configuration.

The GitOps Gap: Why Have Only 40% Actually Adopted It?

Surveys show that while over 50% of cloud-native deployments use GitOps-related concepts or tools, only about 40% actually manage state through declarative configuration. Where does this gap come from? After some reflection, I’ve identified a few key reasons.

1. Mistaking CI/CD for GitOps

Many teams think: “We have Jenkins, code changes trigger automatic builds and applies to K8s clusters — isn’t that GitOps?”

Wrong. ❌

If you’re missing automated reconciliation — the mechanism that automatically pulls the cluster back in line when actual running state diverges from Git definitions — then you’re just doing traditional CI/CD. At best, it’s Git-driven DevOps.

2. The Firefighting Mentality in Production

When the server is on fire, who’s going to modify YAML in a Git repo and wait for the pipeline to finish? Of course you kubectl edit directly! 😱

I deeply relate to this. Once during a live incident with memory pressure spiking, I SSH’d in and fired off a few kubectl scale commands. The fire was out, but I forgot to update Git. When a colleague deployed next, the replica count got overwritten, and it caught fire again… Yes, this repeated the very next day.

This is a textbook case of configuration drift + single-point knowledge silo, which is exactly what GitOps aims to solve — but paradoxically becomes a barrier to adoption, because many teams are accustomed to defensive operations: if it ain’t broke, don’t touch it; if it breaks, stop the bleeding first; worry about the rest later.

│ 📝Note: I’m not saying you should never use kubectl to modify production — but if you do, you must sync the changes back to Git afterward. Don’t let it become a “ghost configuration.”

3. Tool Selection Paralysis

Argo CD or Flux? This debate can consume an entire day. Here’s my take.

Dimension	Argo CD	Flux
Community Activity	✅ Very active, backed by Red Hat, Intuit, etc.	⚠️ Parent company Weaveworks went bankrupt, funding risk
Visual UI	✅ Built-in Web UI, intuitive	👎 Relies on third-party (e.g., Weave GitOps, but parent company shut down)
Multi-cluster	✅ Single Argo CD instance can manage multiple clusters	✅ Also natively supports multi-cluster
Progressive Delivery	✅ Canary/blue-green via Argo Rollouts	⚠️ Supported but less intuitive
Learning Curve	Medium (many concepts, but well-documented)	Lower (concise config, operator-native)

If you want my recommendation: for smaller teams with moderate experience, go with Argo CD — its visual UI and Red Hat’s ongoing support make GitOps’s “transparency” principle much more tangible.

GitOps Practices That Actually Work

Enough about the gap — let’s talk about what actually works. Combining my company’s lessons learned with practices summarized by The New Stack (reference [2]), here are the 5 practices I consider most worth adopting:

1. Extract Configuration and Separate Environments

Don’t hardcode all environment configs (dev/staging/prod) under a single overlays/ — that’s painful. A more effective approach:

Use Kustomize or Helm for environment differentiation
Handle sensitive data with SealedSecrets or External Secrets Operator + a secrets management platform (officially the latter is preferred, followed by SealedSecrets)
Maintain independent folders per environment in Git

│ 📝Notes: Kustomize is more “K8s-native” than Helm, but Helm has stronger templating capabilities and a richer community ecosystem. My preference: go all-in on Helm. That said, Kustomize for standard apps, Helm for complex middleware/third-party components is also a solid approach.

2. Automated Rollback Mechanisms

This is arguably GitOps’s greatest value. When a deployment fails or configuration drift is detected, Argo CD can automatically revert to the “last healthy state” recorded in the Git repo.

Key configuration example (Argo CD Application):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    retry:
      limit: 3
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m
  syncOptions:
    - Validate=false
    - PrunePropagationPolicy=foreground
    - Replace=true

Setting selfHeal: true with automatic retries lets the cluster self-repair its own configuration drift.

3. Progressive Delivery (Canary/Blue-Green Deployments)

If you want GitOps to be more than an “ops tool” and become a “delivery platform,” you must try Argo Rollouts.

In short, it enables:

Blue-green deployments: traffic switches all at once
Canary deployments: gradually increase traffic to the new version (e.g., 5% → 20% → 50% → 100%), automatically deciding whether to proceed or roll back based on metrics

Canary deployment example:

kind: Rollout
metadata:
  name: my-app-rollout
spec:
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {duration: 2m}
      - setWeight: 50
      - pause: {duration: 5m}
      - setWeight: 100

Commit this Rollout object to Git, and Argo CD will automatically reconcile and execute the canary strategy. This is leagues beyond manually controlling traffic.

4. Continuous Verification and Testing

This is no joke — GitOps and automated testing are a golden combination. Recommendations:

Maintain test artifacts in the Git repo (e.g., PrometheusRules, Grafana dashboard JSON)
Execute smoke tests via Argo CD’s PreSync and PostSync hooks
Use custom health checks

│ 📝Notes: If your API Gateway is also managed via GitOps (e.g., Traefik IngressRoute CRDs), then the entire traffic ingress layer achieves Git-driven full-stack configuration — incredibly satisfying.

5. Don’t Blindly Worship “Git Is Everything”