Plenty of technical ideas survive on vocabulary. GitOps does not need it. In plain terms: your team writes down exactly how its systems should look, keeps that description in a store that preserves every revision, and lets software inside the platform fetch the description and keep the real system matched to it. That is the entire idea. The rest of this article walks through what actually happens in practice \u2014 the loop the software runs, why the direction of travel matters, the boundaries people most often blur, and the worries that surface in every team’s first year. No prior operations background is assumed, and nothing here depends on a particular vendor, because the idea, like most good clinical practice, is older than its tooling.<\/p>\n
Every reconciliation cycle, however sophisticated the product, reduces to the same four moves:<\/p>\n
Then it does all four again. Nobody demands split-second timing; a check every few minutes is genuinely continuous, in the sense that matters, which is that unreviewed changes do not get to live long. The rhythm is closer to ward observations than to emergency response: frequent, systematic, and reassuring mostly because it never skips a round.<\/p>\n
Consider recovery after knee surgery. The discharge pack states the programme: which exercises, at what frequency, progressing by which milestones. The physiotherapist then sees the patient regularly, measures progress against the written programme, corrects what has drifted, and records the visit. The pack is the declared state. The physio is the reconciler. Now remove the physio and leave the pack in a drawer \u2014 nothing improves, and nobody can say the programme failed, because the programme was never executed. That is the difference between storing configuration and operating on it, and it is the single most common half-adoption in this field. The written plan earns nothing until something disciplined checks reality against it, over and over, and gently forces the two back together.<\/p>\n
Engineers say a GitOps description is declarative, and the word intimidates people for no good reason. A declarative description states the destination; it does not narrate the journey. Compare a prescription with a procedure note. The prescription states the target \u2014 this drug, this dose, this duration \u2014 and anyone competent can fill it. The procedure note narrates each step as it happened. Most traditional deployment scripts are procedure notes: step one, copy the files; step two, restart the service; step three, hope. A declared state is the prescription. It says the service runs this version with these settings behind that routing rule, and it says nothing about which commands got there \u2014 which is exactly why the same description can be checked, repeated, and rebuilt by different hands on different days with the same result.<\/p>\n
Direction matters more than it sounds. In the older arrangement, a build server holds production credentials and pushes changes into the platform \u2014 meaning the keys to the ward sit in a building anyone can theoretically reach, and every pipeline misconfiguration becomes a door. In the GitOps arrangement, the platform sends out for its own instructions: an agent inside the boundary reads the store and works outward from there, needing nothing beyond the ability to read. Credentials stay home. The pipeline never touches production; it only publishes new descriptions for the agent to collect. A webhook can hurry things along \u2014 think of it as a text reminder asking the agent to attend its next check early \u2014 but the delivery itself is always the agent’s own trip, on its own schedule, through its own door.<\/p>\n
Each of these deserves one clean sentence, so here are three. First, GitOps is not the same thing as infrastructure-as-code: the code describes state in a particular language, while GitOps is the operating routine that keeps reality matched to it \u2014 the vocabulary and the daily practice of speaking it. Second, it is not a release strategy: deciding whether a new version reaches ten percent of users or all of them is a different discipline that layers neatly on top, the way a rehabilitation protocol differs from the surgery schedule that precedes it. Third, it is not a place for data: the store holds structure \u2014 what should exist, at which versions \u2014 while records, database contents, and everything your users actually created stay in proper storage with proper backups, where auditors and recovery plans expect to find them.<\/p>\n
Three questions come up in almost every early conversation, and each has a calm answer. What happens if the agent stops? Nothing dramatic \u2014 the system keeps running as it is, it simply stops self-correcting until the agent returns, which is why teams watch the reconciler’s own health the way they watch any other always-on component. What if the store becomes unreachable? The agents keep enforcing the last good description they read; change propagation pauses, production does not. What if two teams disagree about what production should be? Under this model that argument happens in one place \u2014 the store \u2014 before either change ships, which is a considerable improvement on the historical method of discovering the disagreement inside the platform at midnight. The pattern behind all three answers is the same: GitOps trades silent, unrecorded flexibility for loud, reviewable agreement, and almost everyone who lives with the trade decides it was underpriced.<\/p>\n
Two names dominate. Argo CD presents a central service with an interface, permissions, and application templates, which suits organisations that want one visible control room. Flux distributes the work \u2014 a small agent on each cluster, doing its own fetching and correcting on local schedules, which suits teams who prefer fewer central parts. Both read the store, both reconcile, both report status, and choosing between them is an architecture decision rather than an ideology. A knowledgeable human summary of the field, with the history and the edge cases filled in, sits in a GitOps primer from xOps School<\/a>, which is the natural second read after this one.<\/p>\n You can diagnose an adopted team without reading a single config file. Changes reach production as reviewed requests, and nobody remembers the last time someone logged into a server to fix something by hand. When an incident review is held, the discussion quotes the store: this definition, this commit, this decision record. New starters spend their first week reading descriptions of systems rather than shadowing veterans, because the descriptions are actually true. The audit question \u2014 who changed what, when, and who agreed \u2014 is answered by exporting a report rather than reconstructing history from memory and chat logs. And releases have become unremarkable. Teams that expected excitement report a mild anticlimax instead, which is precisely what success looks like in operations: the absence of drama, purchased in advance through structure.<\/p>\n Good knee care proceeds by systematic evaluation: history, examination, imaging in proportion, then a written plan that everyone can read \u2014 the approach described in how clinicians evaluate knee pain and set treatment plans<\/a>. Strip the clinical vocabulary and GitOps is that same discipline aimed at servers: observe honestly, compare against a written standard, act proportionately, record the outcome. Readers curious about the wider territory will find the surrounding structure in this site’s piece on the unified architecture of XOps<\/a>, and a practical view of putting such ideas to work in streamlining software and cloud operations<\/a>. Write the destination clearly. Send a disciplined checker around on a schedule. Keep the record where everyone can read it. Very little else in modern operations is genuinely more complicated than that.<\/p>\n","protected":false},"excerpt":{"rendered":" A plain-language walk through GitOps: the four-verb loop, why pulling beats pushing, the boundaries people blur, and the worries worth settling early.<\/p>\n","protected":false},"author":11,"featured_media":2878,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1628],"tags":[],"class_list":["post-2877","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-healthcare-it"],"yoast_head":"\nWhat a healthy adoption looks like six months in<\/h2>\n
The habit this site’s readers already understand<\/h2>\n