insight
GitOps Is a Reconciliation Model, Not Just a Deployment Tool
The real value of GitOps is the continuous comparison between declared and observed state, not the presence of an Argo CD dashboard.
It is easy to describe GitOps as "deploying from Git," but that definition misses the operating behaviour that makes the model useful.
Declaration is only the beginning
Version-controlled Kubernetes manifests create a reviewable desired state. They show what should exist, who changed it, and how to reproduce it. That is valuable, but a repository alone does not keep a cluster correct.
The stronger property comes from reconciliation. A controller continuously compares the desired state in Git with the observed state in the cluster and reports or corrects drift.
A dashboard is evidence, not the architecture
Argo CD's resource tree is useful because it exposes health, synchronisation, and ownership. The dashboard does not create GitOps by itself. The architecture depends on a clear source of truth, declarative resources, automated comparison, and an intentional policy for applying differences.
Design the recovery path
A good delivery workflow makes rollback understandable. A reviewed Git change should be able to restore the previous desired state, while cluster-level failures remain visible rather than hidden behind a successful pipeline step.
Keep responsibilities clear
Continuous integration should build, test, and publish an immutable artifact. The GitOps controller should reconcile deployment configuration. Mixing both responsibilities into a chain of remote shell commands weakens traceability and makes drift easier to introduce.
GitOps becomes valuable when it reduces the distance between what the team reviewed and what the platform is actually running.