Versioning the System

Versioning the desired state

GitOps principles specify that the system configuration or desired state must be stored in a version control system like Git. While this sounds simple, this storage is essential to have success with GitOps. Let's take a deeper look at the powerful role that version control plays in GitOps.

Blueprint analogy

While discussing declarative configurations, we likened the system's desired state to the blueprints for a home. When building a home, the blueprints serve as a means for the homeowner, builder, and workers to agree upon what the house should look like after its construction. If a kitchen is missing from the blueprints, the fully constructed home will not contain a kitchen. If the homeowner wants to make a room in the home larger, it requires an update to the blueprint so that everyone is aligned on the new design.

This same concept applies to GitOps. Similar to how blueprints define the specifications for a home under construction, the desired state of the system determines what a system will look like at runtime. When using GitOps to manage the workloads running on a Kubernetes cluster, Kubernetes manifests serve as these blueprints. If the desired state is missing a particular pod, it won't be present in the running system. If the system must run more instances of a pod, the desired state in Git must be updated to reflect the necessary changes. These system blueprints, or the desired state, are versioned in Git when managing a system with GitOps. This creates a single location that anyone can work from if they are interested in viewing or changing the desired state.

Single source of truth

In GitOps, the desired state in Git ...