← Back to concept explainers

Concept Fable

GitOps

Conclusion first:It treats the Git repository as the single trusted source of the system's desired state, describes infrastructure and application configuration in declarative files, and automated controllers continuously synchronize the actual environment to the state described in Git.

GitOps · DevOps / operations

Read the story first. There is no rush to give a definition here; let the question grow on its own first.

Fable

The city wall is based on the drawings

The city wall of Shinan City was repaired by someone every day. The east gate lacked bricks, so guards patched it temporarily; the west gate needed lamps, so craftsmen installed them directly; at night someone changed the drainage ditch, and the next day no one knew why.

The city wall appeared to be maintained continuously, yet no one could clearly say what it should actually look like now. Different craftsmen repaired it according to their own habits, and the same city wall gradually became several different sets of practices.

The city lord first required daily reports of changes. But reports had omissions, and the criteria were chaotic. When a problem arose, they could only go to the site and check brick by brick; who changed it and why quickly became unclear.

The new chief engineer announced: the city wall would no longer be governed by on-site verbal orders, but by the master drawing repository. Anyone who wanted to change the city wall had to first change the drawings; only after the drawings were reviewed and stamped could they be filed in the repository.

The wall inspector compares the site with the drawings every day. When he finds a discrepancy, he either repairs the site back to match the drawings or reports that the drawings really need updating. This method seems roundabout at first.

Until one erroneous change took down the west gate lamp. The chief engineer turned back to the previous version of the drawing, and the wall patrol officer immediately knew which lamps should be restored. Shinan City finally admitted that stability comes from everyone acknowledging the same desired state and letting the site continually converge toward it.

The craftsman gradually discovered that changing the blueprint first was not an extra hassle, but an extra shared memory. Every change had a reason, a review and a version, so later people could know why the city wall had grown into this shape.

The site would still be damaged by wind and rain, and someone might make a temporary mistaken change. But as long as the blueprint library was a commonly recognized target, the wall patrol officers could pull deviations back. After Shinan City separated the chaotic site from the desired state, maintenance truly became controllable. Later, when newcomers started, the old masters no longer began with abstract terms. Instead, they had them review that failure: where intuition had originally been relied on, why the first repair was not enough, and how the new arrangement kept risk in a place that could be checked. Only when they could explain these details clearly, and also point out when to continue using the approach and when to upgrade it, were they considered to truly understand this method. Later they also had newcomers practice with this method: first let newcomers do it the old way and see how errors appeared; then redo it under the new rules and see which step was blocked earlier and which step left evidence. If newcomers could only recite names, they would still misuse it in similar scenarios; only those who could state the applicable boundaries, costs, and remedies after failure were allowed to take on work independently.

Reveal

This story is about: GitOps

It treats the Git repository as the single trusted source of the system's desired state, describes infrastructure and application configuration in declarative files, and automated controllers continuously synchronize the actual environment to the state described in Git.

The key mechanisms of GitOps include declarative configuration, Pull Request review, automatic synchronization, drift detection, audit history, and rapid rollback. Operations actions do not rely on people typing temporary commands on servers, but drive system changes by modifying traceable Git state.

Metaphor mapping

  • Master blueprint repository: Git repository, storing the desired state
  • Drawings go through review: Pull Request and code review
  • Wall inspector compares against the site: GitOps controller detects actual state
  • Automatically restoring the drawing’s appearance: automatic synchronization and drift correction
  • Rolling back to the previous drawing version: Git history-based rollback

Andy Ren Xu's judgment

The business value of GitOps is reducing uncertainty in delivery environments. For Agent platforms, configurations, permissions, workflows, and deployment states should all be auditable, rollback-capable, and replicable.

IaCKubernetesArgo CDFluxdeclarative deploymentdrift detection

Related distinctions

This concept is easily confused with adjacent concepts; it is recommended to continue to the comparison page.

京ICP备2026014272号