Operations needs a source of truth

DevOps brought build and release automation into the software workflow, but the environments that host and underpin that software still tend to be managed by hand. Day-to-day operational tasks — keeping desired state configuration accurate, avoiding configuration drift, managing access permissions, deploying new environments — have traditionally spanned multiple tools and platforms, been error-prone, and relied on change management frameworks such as ITIL or change advisory boards to reduce risk.

Git repositories already serve as the source of truth for code, giving teams a full versioned history of changes, who made them, and why. The same model can apply to operational tasks. Desired state can live in Git, and automated agents can reconcile the live environment against that declared state.

The GitOps model

The Linux Foundation’s OpenGitOps project defines four principles for GitOps:

  1. Declarative — a managed system must have its desired state expressed declaratively.
  2. Versioned and Immutable — desired state is stored in a way that enforces immutability, versioning, and retains a complete version history.
  3. Pulled Automatically — software agents automatically pull the desired state declarations from the source.
  4. Continuously Reconciled — software agents continuously observe actual system state and attempt to apply the desired state.

In practice, GitOps means describing what you want rather than how it should happen. The declarative, immutable state description lives in Git. An automated agent analyzes the current state against the desired state on an ongoing basis and makes changes to eliminate any configuration drift.

A diagram showing a "Current State" which has a database, an application and some settings. The current state has bi-directional arrows to an "Automated process" (or agent). This agent has bi-directional arrows to a "Desired state", stored in GitHub, which also contains a database, an application and some settings. The diagram also shows a new branch, with a 'proposed desired state', with two databases, two applications and settings. To merge those changes into the 'desired state' in the Git repository, a pull request is needed, after passing any relevant automated checks or manual reviews.

Kubernetes controllers, Flux, and Argo CD are well-known examples of platforms that rely on an agent continuously evaluating the environment against an intended state. Not all platforms have this agent capability built in. Teams sometimes fall back to CI/CD workflows to push desired state changes, but this has tradeoffs: updates are slower (dependent on workflow triggers), and drift detection is not available out of the box. It also violates the third OpenGitOps principle.

GitOps principles extend beyond applications. Infrastructure-as-code tools like Ansible and Terraform describe configuration declaratively, and platforms such as Ansible Automation Platform or Terraform Cloud can reconcile updated configuration across the estate.

GitHub’s Entitlements project

GitHub uses GitOps for identity and access management through its open-sourced Entitlements project, which manages access to applications, distribution lists, and organizational structure. Storing permission mappings in source control gives a clear, auditable source of truth. The repository history explains why changes were made and by whom; pull requests add context from discussions, approvals, and checks.

Good governance matters for these repositories just as it does for software projects. Branch protection rules and repository rules can enforce quality before changes land:

  • Require a minimum number of reviewers to approve changes.
  • Use a CODEOWNERS file to automatically assign required reviewers based on changed files.
  • Lint pull request contributions to ensure they meet expected standards.
  • Execute a dry-run of configuration or permission changes to identify impact before accepting a pull request.

This reduces risky manual changes and lets automation scale operational needs. Operations teams remain fully involved — the role evolves into managing workflows, reviewing proposed changes, and approving or rejecting based on business need.

Several practices help GitOps repositories deliver value reliably:

  • Keep a clear README that explains what the repository is, how to contribute, and what expectations exist around contributions.
  • Apply quality checks directly within pull requests:
    • Use branch protection rules or repository rules to enforce review requirements, disallow direct merges, and require status checks before merging.
    • Use GitHub Actions workflows on the pull request trigger to automate checks:
      • Lint changes to verify they follow standard practices.
      • Run a dry-run such as terraform plan, a Bicep deployment what-if, or the equivalent for your tooling, so you know what will change before merging.
      • Where processes are mature, deploy to a temporary environment and run smoke tests to validate changes outside of production.

Treating operational configuration like code — with guardrails, reviews, and automated checks — is a natural evolution of change management practice, extending the reliability guarantees of modern software delivery to the environments it runs on.