GitOps vs Traditional CI/CD: What's Actually Different

Every few years DevOps gets a new buzzword, and teams scramble to figure out if it’s a real shift or just a rebrand. GitOps is real — but it’s smaller than it sounds.

Traditional CI/CD: push-based

In a classic pipeline, your CI server (Jenkins, GitHub Actions, GitLab CI) builds an artifact, then pushes it to your infrastructure — it runs kubectl apply, or SSHes into a box, or calls a cloud API directly.

Code change → CI builds → CI pushes to production

The pipeline holds the credentials to your production environment. If the pipeline is compromised, so is production.

GitOps: pull-based

GitOps flips the direction. A Git repository becomes the single source of truth for what your infrastructure should look like. An agent running inside the cluster (like Argo CD or Flux) continuously watches that repo and pulls changes to match reality to the desired state.

Code change → CI builds → Git repo updated → Agent inside cluster pulls the change

The CI system never touches production directly. It only ever writes to Git.

Why this matters

1. Smaller blast radius. No external system holds production credentials.
2. Built-in audit trail. Every change to the cluster is a Git commit — who, what, when, why.
3. Self-healing. If someone manually changes something in the cluster, the GitOps agent notices the drift and reverts it back to what Git says.
4. Easy rollback. Rolling back is just git revert.

The trade-off

GitOps adds a layer of indirection. A change doesn’t take effect the moment you merge — it takes effect the moment the agent notices the diff, which is usually seconds but can trip up people expecting instant feedback like a traditional pipeline gives.

The secret ingredient

Don’t think of GitOps as “a tool you install.” Think of it as answering one question: is Git the source of truth for your infrastructure, or is your CI pipeline? If it’s the former, you’re doing GitOps — regardless of which tool enforces it.