May 13, 2026 · 6 min
GitOps Is Not Continuous Delivery: The Difference Matters
Patrick McClory
GitOps and continuous delivery are not the same thing. Most teams conflate them in ways that create real operational problems. GitOps is a deployment and reconciliation model. Continuous delivery is a software delivery practice. They compose well but they're solving different problems, and treating them as synonyms produces systems where neither works as well as it should.
GitOps Is Not Continuous Delivery: The Difference Matters
GitOps came after CI/CD. That ordering matters.
Continuous delivery gave software teams a vocabulary and a practice for getting code from commit to production quickly, reliably, and repeatedly. Trunk-based development, automated pipelines, environment parity, fast feedback loops. These patterns were being refined by development teams for years before anyone used the word GitOps. CI/CD is a software delivery discipline that matured over a decade of practitioner experience.
GitOps took those patterns and applied them to the operations side of the house. Not invented them. Formalized them. The insight was that the same principles that made software delivery reliable could make infrastructure and application deployment reliable. Git as the source of truth. Declarative desired state. Automated reconciliation. Drift detection. Operators that continuously ensure actual state matches what the repo says it should be.
Two disciplines. Related lineage. Different problems being solved.
Most teams that adopt ArgoCD treat this as a distinction without a difference. It’s not.
What GitOps Actually Is
GitOps is a deployment and operations model where the Git repository is the authoritative source of desired state, and an operator continuously reconciles the running system to match that state.
The key word is continuously. Not on pipeline trigger. Not when someone clicks deploy. Continuously, the operator is always watching, always comparing actual state to desired state, always correcting drift. If someone makes a manual change to a running system, the operator detects the drift and corrects it. If a node goes down and comes back up in a different state, the operator reconciles it. If a new version is committed to the repo, the operator applies it.
This is a different model from traditional deployment pipelines. A pipeline is an event-driven process: something happens (a commit, a tag, a button press), the pipeline runs, the deployment occurs, the pipeline exits. The pipeline doesn’t know or care what happens after it exits. If someone SSHes into the server and changes a config file, the pipeline has no opinion about it.
GitOps doesn’t exit. It watches. It reconciles. It enforces. The repo is not a record of what was deployed. It’s a description of what should be running right now, and the operator makes it so.
What Continuous Delivery Actually Is
Continuous delivery is the practice of keeping software in a deployable state at all times and automating the path from code change to production.
This is primarily a software delivery discipline. It lives in the pipeline. It’s about test coverage, build reliability, environment consistency, deployment automation, rollback capability. The goal is that any commit to the main branch could be deployed to production safely, quickly, and without heroics.
CI/CD doesn’t care about reconciliation. Once the pipeline runs and the deployment succeeds, CI/CD is done. What happens to the running system after that is outside its scope. Drift, manual changes, configuration that diverges from what was deployed. CI/CD doesn’t detect or correct any of this. It just gets the software there.
This is not a criticism. CI/CD is solving a different problem. Getting code to production reliably is hard and CI/CD practices solve it well. The problem is treating “we have a pipeline” as equivalent to “we have GitOps,” or treating “we have ArgoCD” as equivalent to “we have continuous delivery.” Neither substitution is true.
The ArgoCD Convertible
Most teams that adopt ArgoCD use it as a fancier way to deploy the same way they always deployed. YAML gets applied to the cluster. ArgoCD shows a green checkmark. The team calls this GitOps.
This is like buying a convertible sports car, never taking the top down, and never driving a single mile over the speed limit. The car cost three times as much as it needed to and you’re getting none of what makes it interesting.
ArgoCD is built for continuous reconciliation. Drift detection. Multi-environment promotion. App-of-apps patterns. GitOps repositories that are the authoritative source of truth for everything running in the cluster. When teams use ArgoCD this way, when the repo describes what should be running and ArgoCD enforces it continuously, the operational characteristics change meaningfully. Manual changes get corrected. Drift gets detected. The cluster state is auditable from the repo history. Rollback is a git revert.
When teams use ArgoCD as a deploy button with a nicer UI, they get none of this. The top is up. The speed limit is respected. The investment is real and the return is marginal.
The distinguishing question: if someone makes a manual change to a running workload, does your system detect and correct it? If the answer is no, you have a deployment tool. You don’t have GitOps.
Where They Compose
The good news is that GitOps and continuous delivery compose well when you understand what each one does.
CI/CD owns the pipeline: the path from commit to a versioned, tested, artifact-in-a-registry. Everything up to “the image is built, tested, and tagged.” This is where build reliability, test coverage, and deployment automation live. The pipeline’s job is to produce a known-good artifact and update the GitOps repository to reference it.
GitOps owns the reconciliation: the path from “the repo says this version should be running” to “the cluster is running this version.” ArgoCD watches the repo, detects when the declared state changes, and applies the change to the cluster. Continuously. Without being triggered by the pipeline directly.
The seam between them is the GitOps repository. The pipeline writes to it (updating an image tag, bumping a version). ArgoCD reads from it (reconciling the cluster to match). Neither system needs to know how the other works. The repo is the contract between them.
When this is working correctly: a developer merges a PR, the pipeline builds and tests the change, pushes the image, updates the image tag in the GitOps repo, and ArgoCD picks up the change and reconciles the cluster. The developer didn’t click anything after the merge. The platform team didn’t get a Slack message. The change propagated automatically through a well-defined seam.
That’s the convertible with the top down, on a road that actually deserves it.
The Practice vs The Tool
GitOps is a practice that uses tools like ArgoCD. It is not a tool called ArgoCD.
The practice requires: a Git repository that is the source of truth for running state (not just a place where manifests live), an operator that continuously reconciles actual state to desired state, a policy that manual changes to running systems are drift to be corrected rather than valid operational procedures, and a pipeline that maintains the repo rather than deploying directly to the cluster.
Most teams have the tool. Few have the practice. The tool without the practice gives you a deployment mechanism with a learning curve. The practice with the tool gives you an operational model where the running system is always what the repo says it should be, drift is automatically corrected, and the history of what ran when is in git.
The difference matters because the value proposition of GitOps, auditability, drift correction, declarative state, self-healing systems, only materializes if the practice is actually followed. Adopting ArgoCD without adopting the practice is adopting the complexity without the benefit.
Take the top down. Drive the car.