GitOps is a term coined by Alexis Richardson a few years ago and has grown immensely in popularity. In a nutshell, GitOps is a set of principles for operating and managing software systems, derived from modern software operations, but also rooted in pre-existing and widely adopted best practices. However they differ in specific ways from traditional CI & CD pipeline approach that has dominated the industry for decades. Last year, Amazon, Azure, Codefresh, Github, Redhat, and Weaveworks teamed up to launch the GitOps Working Group under the CNCF. The goal was to formalize all the ideas that have developed around GitOps into a single cohesive set of principles that would be easily digestible and repeatable by any organization.
We’re very proud to announce that over 60 companies, 96 interested parties, and 34 co-authors have brought the best of DevOps into the OpenGitOps 1.0 Principles and Glossary. Each principle discusses the desired state of a system and how it should be operated.
The desired state of a GitOps managed system must be:
Declarative
A system managed by GitOps must have its desired state expressed declaratively.
Versioned and Immutable
Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
Pulled Automatically
Software agents automatically pull the desired state declarations from the source.
Continuously Reconciled
Software agents continuously observe actual system state and attempt to apply the desired state.
GitOps is more than just storing infrastructure-as-code
As git history shows, the wording of each principle and linked glossary item was very carefully chosen. While many of these principles should be familiar to professionals, many are surprised to learn that they still have work to do to implement GitOps fully.
Declarative is usually the easiest principle to understand. Not just infrastructure-as-code but all configuration data that is needed to run a system including the application layer. While this doesn’t generally include persistent application data such as database contents it often includes credentials and configuration for data recovery or data access.
Versioned and Immutable is often understood as “use git” but there is more to it than that. If that desired state describes using a “latest” tag for example, it is no longer versioned because there is no way to rollback changes in the desired state. Likewise, many version control systems can be used in GitOps as long as they meet those two basic requirements and teams use them in a conformant manner.
Pulled Automatically means we have to have software agents constantly observing the desired state. While triggers may exist to speed up that observation, a GitOps system shouldn’t exclusively rely on them. Software agents need to constantly be aware of what the desired state should be, not only when a deliberate change is made. The verb “pull” here is used very clearly in contrast to the way traditional CI/CD pipelines function based on triggers that simply push.
Finally, Continuously Reconciled brings it all together. The GitOps software agents have to be aware of the actual state of a system under management and attempt to apply the desired state. Being constantly aware of both the actual state and desired state means we can detect anytime they are out of alignment whether by changes to the desired state (normal operation) or changes to the actual state (drift), a GitOps software agent should detect this attempt to apply the desired state.
When teams implement these principles and achieve GitOps they deploy more often, have fewer regressions, and are more competitive. They bring together decades of experience delivering software to create a standard that is incredibly powerful and accessible and rapidly being adopted by a growing number of open source tools and vendors.
What’s next
There’s so much more on the horizon and we need your help! This vendor-neutral, principle-led meaning of GitOps establishes a foundation for interoperability between tools, conformance, and certification through lasting programs, documents, and code.
How do you use GitOps? Join us in developing GitOps case studies and best practices, plan GitOps events, and help with the direction of the OpenGitOps project!