Teams working on emerging technology accept a particular discipline without argument: an experiment that cannot be reproduced from its recorded parameters is not finished. Curiously, the same teams then configure the compute platforms underneath those experiments by hand, one console edit at a time, and wonder why “works on the lab cluster” rarely survives contact with the second machine. GitOps applies the reproducibility standard to the platform itself. The desired configuration is recorded as versioned files; an automated agent continuously pulls those files and corrects the running system to match; humans propose changes through reviewed pull requests rather than terminals. The platform stops being a snowflake that grew organically and becomes a setup anyone on the team can rebuild from the record. What follows is a precise runbook — seven steps, in order, with the reasoning attached — for taking one small service from hand-edited to self-correcting. For the principles and tool detail behind each step, xOps School’s GitOps handbook is the reference this runbook condenses.

Step One: Choose the GitOps Store and Fix the Layout

Pick where the declared state lives: a Git repository is customary, but a container registry or a versioned bucket satisfies the same requirements — the store must keep full history and refuse silent rewrites. Then commit to a directory layout before writing a single file. The reference arrangement uses top-level folders for clusters, infrastructure, tenants and applications, with each environment as a directory rather than a branch. That last choice is the one beginners resist and veterans defend: branch-per-environment hides the staging-versus-production delta inside merge commits, while directory-per-environment prints it on the screen for every review. Reproducibility begins with parameters you can actually see.

Step Two: Declare One Small Service

Write the desired state for a single, low-stakes application — its workload, its service, its configuration — and nothing else. Resist the urge to onboard the whole platform; the first loop should close around the smallest thing that matters. If the service renders through Helm or Kustomize, render the output in your pipeline and attach it to the pull request, so reviewers read the final result rather than reverse-engineering templates. Each overlay should change exactly one value, so every approval is one decision rather than a bundle of them. The habit sounds pedantic for a week and then becomes how your team argues productively.

Step Three: Bootstrap the GitOps Agent So It Manages Itself

Install the reconciler — Argo CD or Flux — and immediately point it at the directory describing the agent’s own configuration. From then on the tool upgrades and reconfigures itself by the identical merge-reviewed route every other change travels, which removes the classic failure mode of an unmanaged control plane drifting from the discipline it enforces. This step is the model’s equivalent of calibrating the instrument with the instrument: after it, every component in the platform, including the one holding the leash, answers to the store.

Step Four: Sync by Hand Before You Automate

Run the first syncs with automation off and a human pressing the button. Read every diff. Watch what the agent intends to create, modify or delete, and build confidence that its idea of “correct” matches yours. Disagreements you discover here cost minutes; the same disagreements discovered after automation cost an incident review. Manual sync is not a lesser mode — it is the training-wheels configuration, and practitioners recommend it so universally that skipping it should be considered a defect in your rollout plan. When reviewing each change produces no surprises three times in a row, you are ready for the next step.

Step Five: Enable GitOps Reconciliation and Write the Drift Policy

Turn on continuous reconciliation for the staging instance of your service, then write down — before the first disagreement — how each class of difference will be treated. The standard policy has four dispositions, and yours should name which resources get which:

• Revert unauthorised changes, returning the resource to its declared form automatically.
• Tolerate fields that other systems own, such as replica counts an autoscaler adjusts.
• Alert and wait for a human, for anything ambiguous or unfamiliar — an unfamiliar field is a question, not an instruction to destroy.
• Protect stateful resources — volumes, namespaces, custom definitions — from automated deletion entirely, no matter what the diff says.

With the policy recorded, let the loop run for a fortnight. Hand-edit something and watch it snap back. Pause the reconciliation, edit again, and watch nothing happen — proof that the suspend lever works before an emergency needs it. The correction arriving without a ticket is the moment most teams say the practice finally made sense; the paused edit being left alone is the moment they trust the off switch.

Step Six: Add the Webhook, Then Guard It

Polling alone is correct — a check every couple of minutes is fully within the model — but a webhook invites the agent to pull immediately after each merge, shaving minutes off routine changes. Configure it with a shared secret: the endpoint enforces no rate limit of its own, so leaving it unsigned amounts to publishing an open door. Verify the webhook’s behaviour by merging a trivial change and confirming the convergence time drops; then stop thinking about speed, because the loop, not the trigger, is the product.

Step Seven: Migrate Deliberately and Keep the GitOps Loop Honest

Expand coverage one slice at a time — a namespace here, a service family there — keeping automated pruning disabled until each team has watched the agent behave for a couple of weeks. Deletion is where trust is won or lost: keep it a human decision early, then guard it with retain policies on stateful resources and a pipeline check that catches deleted namespaces and volumes before anything merges. From the first week, measure: record how long a merge takes to become a healthy workload, count drift events, note reverts. Publication-quality baselines exist — reference labs report medians near four minutes with a long tail — but your own numbers are the ones that matter, and they only exist if you start collecting them now. Plot them where the team meets. A number nobody sees is a number that stops improving. Finally, put three maintenance rituals on the calendar and treat them as part of the experiment: upgrade the reconcilers as production-critical components, rotate their keys on schedule, and rebuild a whole cluster from the store alone each quarter. The rebuild is the reproducibility test for the platform itself — the day it succeeds uneventfully is the day your lab’s infrastructure finally meets the same standard you demand of your science.

For teams already thinking about where the optimisation potential lies, the same mindset extends outward: our explainer on how quantum computing changes machine learning covers a field whose experiments will demand exactly this level of platform discipline, and readers weighing where automation genuinely beats manual effort will enjoy the analysis in how quantum algorithms tackle hard optimisation problems. Declared infrastructure will not make your algorithms faster — but it will make every result easier to believe, which in this field is worth more than a millisecond. Run the seven steps in order, resist every shortcut that skips the manual phase, and the loop you end up with will be boring in exactly the way good infrastructure should be.