Working support for other people’s platforms means inheriting their assumptions, and few topics arrive with more attached folklore than GitOps. A client says it confidently in a kickoff; a handover document claims it vaguely in a diagram; and then the on-call rotation discovers what the word actually meant, usually at the least convenient hour. After enough of those calls, we started collecting the myths \u2014 writing down each misconception verbatim, then working out the shortest honest correction for it. Here are the six that come back most often, each with the version we now give clients \u2014 friendly, but straight. None of them require ill will to believe; that is what makes them worth naming.<\/p>\n
This is the grandparent of them all. A repository full of manifests is storage, nothing more, until something actively reads it and corrects the running system to match. That read-and-repair loop \u2014 pull, compare, reconcile, repeat without end \u2014 is the practice itself; the files are merely what feeds it. We have inherited environments with immaculate repositories that nobody’s cluster had ever consulted. The tell is simple: ask what happens when someone edits production by hand. If the answer is “nothing”, whatever they have, it is not this.<\/p>\n
No tool session starts with this one explicitly, but half of them end here. Continuous integration keeps doing its job \u2014 building, testing, scanning \u2014 and does it well. What shifts into the repository’s hands is the deploy step alone. A pipeline that ends by running an apply command against production is not converted; it is exactly the pattern the pull model exists to retire. The confusion matters commercially, because teams sometimes cancel the wrong contract: keep the build automation, replace the push plumbing.<\/p>\n
Kubernetes is where the practice grew up, not where it stops. The same declared-and-reconciled pattern manages cloud resources through tools such as Crossplane and tofu-controller, and the store need not be Git at all \u2014 a container registry or a versioned bucket meets the bar, which some teams cheerfully call “Gitless GitOps”. For support teams the practical consequence is scope: when a client says “we run GitOps”, ask what surface it covers. You may find cloud infrastructure and platform add-ons reconciled alongside the workloads, and your runbooks should know it.<\/p>\n
Commits record intent: what someone wanted merged, and when. They say nothing about what the agent did next \u2014 what it applied, what it corrected, what errored out at two in the morning. Argo CD’s documentation concedes this openly, and our audit-support work confirms it: evidence packs need reconciler events sitting next to the commit log. The repository answers “what was supposed to happen?”; the events answer “what actually happened?”. An auditor will ask both questions, and clients who learn this during the audit rather than before it tend to remember the lesson expensively. Our advice is cheaper: export the reconciler’s event history into the same archive as the repository and let the two stories corroborate each other.<\/p>\n
We hear this one most from teams who have never lost anything. Git declares systems; it does not contain their contents. Database rows, volume data, the messages sitting in a queue \u2014 none of it lives in the repository, and no reconciliation will bring it back. A client once told us their “disaster recovery” was a fresh cluster and a git clone; the drill that followed was an education. Backups remain a separate discipline with its own restore tests. If you support such an environment, check that the backup schedule exists and has been restored from at least once \u2014 that single question has saved clients more than any tooling we have recommended.<\/p>\n
The friendliest-sounding and the most dangerous. Merging into a watched path is the same as holding deploy rights \u2014 whoever can land a commit there can reshape production, whatever the org chart claims. That includes non-humans: AI coding assistants now open pull requests against real repositories, and an assistant writing to a watched path is a deployer in every sense, deserving the same scoped, reviewed treatment as a junior with production keys. We ask clients three questions:<\/p>\n
The silence after the third question tells you most of what you need to know about a client’s GitOps maturity.<\/p>\n
None of these myths survive contact with the real model, and the real model is genuinely supportable \u2014 arguably more supportable than what it replaces. The desired state is written down; an agent enforces it continuously, so the “who touched what” mystery shrinks; drift surfaces as an alert that already includes the difference, not as a hunch to be chased. The obligations are modest and learnable: keep the reconciliation loop actually running (it is the model, not an optional extra), pair the commit log with reconciler events for evidence, protect deletion behind guards, and scope every writer \u2014 human or otherwise. For a fuller picture than a support desk needs, the complete GitOps reference at xOps School<\/a> lays out the principles, the tools and the counterweights with sources.<\/p>\n Because myths travel by shorthand, we end every relevant kickoff with the same five-minute test. It fits in a notepad and it settles, quickly, how much of the client’s claim is load-bearing:<\/p>\n Five questions, no slides, and by the end everyone in the room knows whether the word on the kickoff poster was a practice or a mood. Run it with warmth \u2014 most teams genuinely believed the folklore, and the test gives them a graceful path to fixing it rather than an accusation to defend.<\/p>\n A closing thought for colleagues who feel their way into this work mid-career: none of this is a new profession, it is the old one with better instruments. The instincts you already have \u2014 verify the claim, test the restore, ask who has access \u2014 are precisely what separates a real adoption from a repo full of YAML. Our overview of DevOps role titles and career paths<\/a> shows where support sits in the modern map, the journey from infrastructure as code toward SRE<\/a> explains why declarative instincts pay off, and the fundamentals in DevOps principles for effective software delivery<\/a> round out the base this practice stands on. Myths fall quickly once someone on the desk knows what to ask \u2014 and now you do.<\/p>\n","protected":false},"excerpt":{"rendered":" Support and managed-services teams inherit other people\u2019s assumptions. Six GitOps myths we debunk at the desk, with the honest version of each.<\/p>\n","protected":false},"author":8,"featured_media":5182,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3948],"tags":[],"class_list":["post-5181","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops-support"],"_links":{"self":[{"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/posts\/5181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/comments?post=5181"}],"version-history":[{"count":1,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/posts\/5181\/revisions"}],"predecessor-version":[{"id":5214,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/posts\/5181\/revisions\/5214"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/media\/5182"}],"wp:attachment":[{"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/media?parent=5181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/categories?post=5181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/tags?post=5181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}A Pocket Test for Client Kickoffs<\/h2>\n
\n