Aviation built its safety record on questions asked in advance and answered from written references, not from memory. Software operations is catching up, and GitOps is where the two disciplines sound most alike: a written, versioned account of how every system ought to be configured, a software agent that pulls the description by itself and steers the live environment to match, and a hard rule that changes reach production through reviewed merges rather than through someone’s keyboard at an odd hour. The questions below are the ones engineers at flight schools, charter operators and aviation-adjacent software teams ask first, answered in the order they usually come up.
The Ground School Briefing on GitOps
Before the questions, one paragraph of shared vocabulary. The tool doing the steering is called a reconciler, and the two names to know are Argo CD and Flux. It keeps the authoritative description of your systems in a repository, reads that description repeatedly, observes the live environment, computes the difference, and applies, prunes or rolls back until the two agree. Production changes are proposed the way maintenance discrepancies are: written down, reviewed, approved. If a term below is unfamiliar, xOps School’s reference page on GitOps defines it with sources; the answers here stay deliberately short.
GitOps Questions, Answered in the Order They Get Asked
Which four principles decide whether something counts?
Four tests, all of which must pass. The desired state is expressed declaratively — the destination is stated, not the steps. That description is held in a versioned, immutable store, so last week’s exact state can be reproduced. Software agents pull it on their own schedule rather than receiving pushes. And the matching of live system to description is continuous, not a one-time event — a poll every three minutes qualifies, because the commitment is to eventual agreement, not to speed. These are the OpenGitOps principles, and they function like a airworthiness checklist: an item is either satisfied or it is not.
We already deploy from CI with kubectl apply. Isn’t that the same thing?
No, and the four tests above show exactly where it falls short. A pipeline that pushes changes into a cluster satisfies, at best, two of the principles: there is no agent pulling on its own authority, and no continuous reconciliation after the job ends. The moment the run finishes, nothing is watching. The deployment also carries the cluster’s credentials inside your CI system, which broadens the blast radius of any compromise there. Precise teams describe that setup as deployment automation — worthwhile, but a different category.
Does the repository literally have to be Git?
Strictly, no. Any versioned, immutable store will serve: an OCI registry holding signed artifacts, or a versioned object bucket. Practitioners call the variants “Gitless GitOps”. The essential property is the immutable history, not the brand of version control. Most teams still pick Git because review tooling and familiar workflows come with it, but the principle does not mandate it.
Where do secrets live if everything is in a repository?
Outside the repository in plaintext, always. Three patterns cover the field. Encrypted-at-rest approaches such as SOPS with age keys keep ciphertext in Git and keys elsewhere. Sealed Secrets encrypts values so that only its in-cluster controller can decrypt them, while the External Secrets Operator skips the repository altogether and syncs what is needed from a dedicated store at run time. What all three share is the guarantee that a person with read access to your repository still cannot read your production credentials — the pull model’s quiet security benefit.
Argo CD or Flux — how do we choose?
By topology preference, mostly. Argo CD runs on a hub model: one central installation, a UI your whole team can read, AppProjects for tenant boundaries, ApplicationSets for pattern-generated applications, and sync waves for ordering. Flux spreads out instead — one light agent on each cluster, controllers divided by job, ordered dependencies declared with dependsOn, drift corrected on an interval, commit signatures checked before anything lands. Large estates often end up running both, each where it fits. Neither choice is wrong; the expensive choice is switching without a reason.
What about progressive delivery — does that come along too?
Not automatically, and it helps to keep the boundary clean. GitOps delivers a declared state; canary analysis and staged rollouts are a release strategy layered on top. When you want them, Flagger and Argo Rollouts sit beside the reconciler and automate the traffic shifting. The two combine well, but a team that conflates them tends to buy one while expecting the other.
How does a rollout actually flow, end to end?
A reviewed pull request is merged. The agent, on its next pass, pulls the updated description. It observes the live state, computes the difference, and applies, prunes or rolls back until reality matches the merge. It then reports what it did. The human decisions all happen before the merge; after it, the loop is mechanical. That narrowing of human action to the review step is where the safety benefit lives.
What is the first deployment mistake to avoid?
Migrating your most critical system first. The working pattern is narrower: stand up the reconciler, let it manage itself, then move over one low-risk namespace at a time with destructive cleanup disabled. Watch a full week of ordinary operation before letting the tool prune anything, and keep a rehearsed way to pause it. Most first-month failures trace back to impatience with exactly this sequence.
Do we need a webhook to make it fast enough?
A webhook only causes the next scheduled poll to happen sooner; it does not change the model. Polling intervals measured in tens of seconds — Argo CD adds jitter to its roughly two-minute cycle — are adequate for nearly every change a normal team ships. If you do add a webhook, put a shared secret on it, because that URL will accept requests from whoever finds it. Aviation analogy, since you asked: it is a priority taxi clearance, not a shorter runway.
Is any of this relevant to a flying school’s own website?
More than it first appears. A school’s web presence is a small estate with high variance: enrolment pages before each intake, fleet announcements, schedule changes during weather disruptions, and a booking form nobody may silently break. Those are exactly the conditions — few staff, many small changes, high cost of embarrassment — where declaring the desired state and letting an agent enforce it pays off. The discipline scales down better than most practices borrowed from large platform teams, because its core requirement is not infrastructure; it is the habit of writing changes down before making them.
Where the Aviation Parallel Actually Holds
The deepest similarity is not the checklist habit; it is the division of attention. Modern engine care pairs scheduled human review with continuous machine observation — the approach described in AI for aircraft engine health monitoring mirrors reconciliation: sensors compare live behaviour against a known-good baseline and flag divergence for a human decision. Inspection works the same way; computer vision applied to aircraft inspection compares what is against what should be, at a frequency no manual rota could sustain. GitOps applies that pairing to configuration: machines watch continuously, people decide deliberately.
The Short Answers, All in One Place
- Four principles, all required: declared state, versioned store, pulled automatically, reconciled continuously.
- CI pushing changes is deployment automation, not this practice — two principles short.
- Git is conventional, not mandatory; immutable versioning is the actual requirement.
- Secrets stay decryptable only in the cluster, by one of three standard patterns.
- Pick the reconciler that matches your topology, not the one with the louder launch blog.
- Start with the tool managing itself, expand one namespace at a time, prune last.
Bring the remaining questions to your own standup — and when the answers there run thin, the reference linked above has the depth this page deliberately skips. The pattern to take away is the one aviation has taught for a century: decide on the ground, in daylight, with the written reference open, so that the work itself is the easiest part of the day.