What GitOps Differs From and What It Stands On — Related Practices and Patterns

In one line

IaC and CaC go only as far as "write the state in files," CI/CD is "automate with pre-defined triggers," and GitOps adds on top of that the part where an agent pulls by itself and reconciles whenever there is divergence. A pattern is a choice of where to put this reconcile loop and when to wake it.

Why this was needed

The Related Practices domain (16%) of CGOA asks you to tell GitOps apart from its neighboring concepts. In practice you often hear "we keep Terraform in Git, so it's GitOps" and "Jenkins runs kubectl apply, so it's GitOps," but judged against the OpenGitOps principles, both are only half right. That is because Principle 3 (Pulled Automatically) and Principle 4 (Continuously Reconciled) are missing. Only when you know the boundary exactly can you say what must be added to make it GitOps.

The Patterns domain (20%) is the next question. Whether to put the reconciler inside or outside the cluster, whether to pull periodically or wake it with events, how to fit progressive delivery into the GitOps loop, and whether to keep the state store as Git alone. Each choice has a reason that the official documentation spells out.

How it works

Related practices — told apart by the CNCF glossary definitions

Practice	Definition in the CNCF glossary	Relationship to GitOps
IaC	Stores infrastructure definitions as files to replace manual provisioning. A single source of truth, managed in a CI/CD pipeline	Fills Principles 1 and 2 (declarative, versioned and immutable). Principles 3 and 4 may or may not be present depending on the tool
CaC	Version-controls configuration like code. Kelsey Hightower's words on opengitops.dev, "GitOps is the best thing since configuration as code," sum up the relationship	The repository is the same, but GitOps moves the party that applies changes from a person or pipeline to an agent
DevOps	One team owns the entire process from development to operations. A shift in culture and process that reduces handoffs	GitOps is one of the operating methods that implement that culture
DevSecOps	Combines security responsibility into DevOps. Enforces security without blocking developers, through automated CI/CD workflows and policy enforcement	Git's review and audit history and the reconciler's least privilege are where that policy enforcement sits
CI	Integrates code changes as often as possible. Starts at a commit and ends in a tested artifact	GitOps does not replace CI. The declaration that references the artifact CI produced is GitOps's input
CD	Automatically deploys changes to an acceptance environment (production, in the case of continuous deployment). Includes testing and rollback procedures	Traditional CD pushes in with a trigger (push), while GitOps has an agent pull

The OpenGitOps glossary explains pull like this. The agent must be able to access the desired state in the state store at any time, not only when there is a change, and only then is the continuous reconciliation of Principle 4 possible. Traditional CI/CD runs automation on a "pre-defined trigger," but GitOps reconciliation happens whenever there is divergence, and divergence arises not only when you deliberately roll out a new version but also when the actual state has drifted unintentionally. Feedback is a term from the closed loop of control theory; it means what effect a previous apply attempt had on the actual state, and the agent retries, rolls back, or raises an alert accordingly.

Pattern 1 — pull intervals and event-driven reconciliation

For both reconcilers, the default is periodic pull. Argo CD polls Git, OCI, and Helm repositories every 3 minutes, and a Flux Kustomization reconciles every 5 minutes (.spec.interval). To remove this delay, both accept webhooks. Argo CD receives push events from GitHub, GitLab, Bitbucket, Azure DevOps, and others at the API server's /api/webhook, and Flux's notification-controller Receiver (port 9292) receives events from GitHub, GitLab, Harbor, Jenkins, and others, making "the pull pipeline as reactive as push."

What matters is that a webhook does not break Principle 3. The Argo CD documentation does not trust the webhook payload, and says that even if an unauthenticated event arrives, all it does is a refresh that happens every 3 minutes anyway. An event is only a signal to "pull now" and does not push state in. Event-driven reconciliation does not replace pull; it brings the timing of the pull forward.

Pattern 2 — is the reconciler inside or outside the cluster?

An in-cluster reconciler reconciles the cluster it runs in. That is Argo CD's destination.server: https://kubernetes.default.svc, and Flux manages even itself the same way through bootstrap. An external reconciler reconciles multiple clusters from one place. Argo CD registers the target cluster's credentials as a Secret (name, server, config) carrying the label argocd.argoproj.io/secret-type: cluster, and can narrow the access scope with namespaces. The Flux documentation also says "one cluster can manage apps on the same cluster or on another cluster." The difference is where the credentials gather. With in-cluster, each cluster holds only its own, and with external, the management cluster holds the credentials for all clusters.

Pattern 3 — putting progressive delivery inside the loop

The Flux glossary defines progressive delivery as "releasing a new feature to some users first, observing and adjusting, and then deploying to everyone," and lists canary, A/B, and feature flags as techniques. In Flux a separate controller called Flagger handles this, and in Argo it is Argo Rollouts. Argo Rollouts manages ReplicaSets with a Rollout resource instead of a Deployment, proceeds according to the strategy (blue-green, canary) when spec.template changes, and marks the new ReplicaSet as stable if it passes metric analysis. From the GitOps point of view, the key is that the deployment strategy itself is part of the declaration (desired state). Git records both "the new image" and "increase in 10% steps while watching the error rate," and the reconciler slowly converges according to that declaration.

Pattern 4 — what to use as the state store

The OpenGitOps glossary defines the state store as "a system that stores the desired state in immutable versions and provides access control and auditing," and says that Git is the origin of the name and the representative example, but other systems that meet the conditions also qualify. Flux implemented "Gitless GitOps" with OCIRepository and OCI artifacts. Users still manage state with Git, but the controller looks only at the container registry, so the Git server drops out of the operational dependencies. Argo CD also accepts Kustomize, Helm, OCI images, YAML directories, and plugins as sources. Conversely, Argo CD's --local manifest upload is a development feature that the documentation itself calls "an anti-pattern of GitOps."

What it looks like in the field

A team that had been deploying with kubectl apply from Jenkins attached Argo CD and left Jenkins's apply step in place. The two parties ended up reverting each other over the same resources, and Argo CD kept reporting OutOfSync. The problem disappeared when CI's role was reduced to "build the image and change the tag in Git." This is a typical case of what happens when the boundary between CI and GitOps is not drawn.

In progressive delivery, it is easy to miss that an automatic rollback turns back the traffic and the ReplicaSets but Git's declaration stays as it was. The reconciler still sees the new image as the desired state, so the same attempt can repeat until a person rolls Git back. You need a procedure that finishes the rollback with a Git commit.

What to look at in the next reading

In the reading that follows, you directly compare the structure of the two tools that implement these patterns, Argo CD and Flux, and see where notifications, observability, and CI integration attach. References: OpenGitOps Principles, GitOps Glossary, CNCF Glossary — GitOps, Argo CD Webhook Configuration, Flux Core Concepts, Flux Webhook Receivers.