- Runs against
- One cluster and what deploys to it
- Deployment becomes
- A merge; rollback becomes a revert
- You get
- A reconciler, a promotion path, an admission policy
Drift is something you should be told about
Git holds the desired state of the cluster; a reconciler makes the cluster match it. Deployment becomes a merge and rollback becomes a revert. That much is the usual description, and it is true.
The property that actually matters is quieter. When the repository is the desired state, the difference between what you meant and what is running becomes a thing the system can compute and report. Without it, drift is not absent — it is merely undiscovered, and it is usually discovered during an incident, by someone reading a live cluster at two in the morning.
So we set up the repository, the reconciler and the promotion path, and we make drift visible before we make it automatic.
What the work covers
- Desired state in Git Manifests, configuration and policy in one reviewed repository layout, with the differences between environments explicit rather than folkloric.
- Reconciliation Argo CD or Flux continuously comparing the cluster against the repository, correcting drift and reporting what it corrected.
- Promotion as a pull request The difference between staging and production is a diff, and a named person approves it.
- Secrets without plaintext in Git Sealed or externally held, referenced by the manifests rather than contained in them.
- Policy at admission What cannot be deployed at all, enforced by the cluster through OPA or Kyverno rather than by the vigilance of whoever is reviewing at the time.
- Rollback as revert Bounded by the reconcile interval, and rehearsed before you need it.
- Reconciliation you can exclude from Replica counts an autoscaler owns, fields an operator writes back, and the break-glass path — declared as exceptions, because a reconciler that fights them is a reconciler the team switches off.
One caveat the slogan hides: a revert undoes a manifest, not a migration. Reverting the commit that shipped a schema change gives you the old code against the new database, which is frequently worse than the problem it was meant to fix. We write down which changes are revertible and which need a forward fix, and that list is part of the handover rather than something discovered during the first incident.
How the engagement runs
Four stages, each ending in something you keep. No weeks are attached: the length follows how much of the cluster is currently described anywhere, which is rarely as much as people expect.
- Stage 1 Repository design What lives in Git, what deliberately does not, and how environments differ. Getting this wrong is the thing that makes teams abandon GitOps six months later. You get: a repository layout, and a written boundary for what stays out of it.
- Stage 2 Reconciler Installed against one namespace, in report-only mode first — drift made visible before it is made automatic, because the first drift report is usually surprising. You get: a drift report for one namespace, before anything changes on its own.
- Stage 3 Promotion and policy Environments promoted by pull request, and admission policy live, so the deployments that must never happen cannot. You get: a promotion path, and an admission policy the cluster enforces.
- Stage 4 Cutover Direct cluster access removed as the routine path, and both a drift event and a rollback rehearsed while everyone is awake. You get: Git as the only routine way in, and both recoveries practised.
What you leave with
- The repository layout — and the written statement of what stays out of it.
- A reconciler — correcting drift, and telling you what it corrected.
- A promotion path — dev to staging to production, each step a reviewed diff.
- An admission policy — enforced by the cluster, not by review discipline.
Why we argue it this way
We have not published a method for GitOps specifically, and we will not cite ourselves as though we had. But the distinction this service rests on is the same one we make about agent systems, one layer up: the control plane and the execution plane.
Git is the control plane — where intent is decided and reviewed. The cluster is the execution plane — where things actually happen, and where every action should be limited, observed and reversible. The commit history and the drift reports are the evidence plane: whether the team can prove what happened. It is the same argument about the same three questions, applied to infrastructure rather than to agents, which is why one firm sensibly does both.
Admission policy is the same move again. We argue that an agent’s irreversible actions should be gated before the side effect rather than reported after it, and enforced somewhere the actor cannot argue with. For a cluster that somewhere is admission control: a deployment that must never happen is refused by the cluster, not caught by whoever happens to be reviewing that afternoon.
Tell us whether anyone could say, right now, how your production cluster differs from what is in your repository. The answer is the engagement.
Talk to usRelated services
Cloud Operations
Accelerate your product development and delivery with our expert DevOps services.
Migrate to Cloud
Seamlessly migrate to the cloud with our expert guidance and support.
Product and MVP Engineering
Design it, prove it with an MVP, then build the software that outlives the prototype.