What is GitOps, and what does a typical GitOps setup look like?
GitOps is modern infrastructure as code in which a Git repository is the single source of truth and changes reach the infrastructure through pull requests ("operations by pull request"). A typical repo has branches for Development, Testing/UAT and Production.
* Every change goes through a pull request; after the merge a GitOps tool brings the environment in line with the repository. *
In GitOps nobody changes the infrastructure directly. To change something you:
- edit the desired state (config, manifests) in Git,
- open a pull request, which colleagues review and automated tests check,
- merge it, after which automation applies the change to the matching environment.
A typical setup is a (for example private GitHub) repository with branches named after the environments:
- Development: where changes are tried first,
- Testing / UAT (User Acceptance Testing, where users or the business confirm the change does what they need),
- Production.
Promoting a change from testing to production is then simply a merge from one branch to the next. That gives every change an author, a review, a timestamp and an easy rollback: revert the commit.
Go deeper:
GitOps (gitops.tech) — push- vs pull-based GitOps, with diagrams.
OpenGitOps — the four GitOps principles from the CNCF working group.