IAC / A CONCEPT NOTE
GitOps
git as the single source of truth for deployments
Overview · mechanism
pitfall · examples
01 / THE SHORT VERSION
The idea in a few sentences.
A Git repository holds the desired state of your infrastructure and applications. An operator (ArgoCD, Flux) continuously syncs the cluster to match the repo. Any change is made via pull request — reviewed, merged, then automatically applied. No kubectl on production machines.
02 / FOLLOW THE MECHANISM
How a gitops deployment flows
Developer
opens a PR modifying Kubernetes manifests, Helm values, or Kustomize overlays.
CI pipeline
lints, validates, and optionally renders the manifests. If checks pass, the PR is merged.
GitOps operator
polls or is webhook-notified of the new commit on the target branch.
Operator
diffs the cluster's live state against the new desired state from Git.
Operator
applies the diff — creates, updates, or deletes resources — and reports back the sync status.
04 / COMMAND NOTES
Read the command, then the result.
Inspect the flags and arguments before trying an example. Snippets can need local setup, replacement values, or resources in your own environment.
manually trigger a sync
argocd app sync APP_NAMEcheck sync status and health
argocd app get APP_NAME05 / CHECK YOURSELF
Could you explain GitOps to a teammate?
Try it out loud in two sentences: what it is, and the one detail that changes the picture. If you stall, the gap is the part to reread.
Up next in Infrastructure as codeInfrastructure as Codemanaging infrastructure through machine-readable definition files