1) Declarative desired state
The first principle requires that your entire system—both infrastructure and application configuration—be defined declaratively. In practice this means storing what the final state should be, not how to achieve it. Declarative manifests (for example, Kubernetes YAML or Helm charts) express the intended state in a machine-readable format. This differs from imperative operations (one-off CLI commands or ad-hoc scripts), which do not capture the resulting state and are harder to reproduce, audit, or recover.Declare the desired state so the system can be inspected, versioned, and reconciled automatically.
- Versioning and diffability of configuration
- Easier peer review (PRs for desired-state changes)
- Deterministic rollouts and rollbacks
2) Use Git as the single source of truth
Store all desired-state definitions in Git. Git gives you an immutable, versioned history and an auditable record of changes, making it the natural single source of truth for your system configuration. Using Git enables:- Clear change history and accountability
- Reproducible rollbacks by reverting commits
- Policy and security enforcement via code review workflows (pull requests)
- PR-based change proposals with automated validation
- Branch-per-environment or directory-per-cluster organization
- Git hooks and CI to run tests and linters against manifests
3) Apply changes automatically
With desired state stored in Git, software agents (GitOps operators) should automatically apply those changes to your environments. Operators continuously watch Git repositories and sync the declared manifests to the runtime environment (for example, Kubernetes clusters). A typical declarative manifest stored in Git:- Continuously pulls manifests from Git
- Applies the manifests to one or more clusters
- Can manage multiple clusters from the same repository structure
4) Continuous reconciliation (self-healing)
Continuous reconciliation is the observe → diff → act loop that keeps the actual state aligned with the desired state:- Observe: The operator watches both the Git repository (desired state) and the live system (actual state).
- Diff: It computes differences between desired and actual states.
- Act: If drift is detected, the operator takes corrective actions to bring the system back into alignment.
- Automated self-healing of configuration drift
- Faster recovery from human or system errors
- Consistent environments across development, staging, and production
Summary table
| Principle | Why it matters | Example |
|---|---|---|
| Declarative desired state | Enables versioning, inspection, and reproducibility | Kubernetes manifests or Helm charts |
| Git as single source of truth | Auditability, history, and rollback capability | git repo with PR-based workflow |
| Apply changes automatically | Consistent, automated deployments | Argo CD or Flux syncing repo to cluster |
| Continuous reconciliation | Self-healing, drift detection and correction | Operator observe → diff → act loop |