Most of us, noticing another new term in the IT blogosphere or conferences, sooner or later ask a similar question: “What is this? Another buzzword, or really something worth close attention, study and promises new horizons? ” The same thing happened to me with the term GitOps some time ago. Armed with a lot of existing articles, as well as the knowledge of colleagues from GitLab, I tried to figure out what it is, and how its application might look like in practice.

By the way, a recent survey we conducted also speaks about the novelty of the term GitOps: more than half of the respondents have not yet started working with its principles.

So, the problem of infrastructure management is not new. Many cloud providers have been available to the general public for a dozen years and, it would seem, should have made the work of the teams responsible for the infrastructure simple and unpretentious. However, when compared with the application development process (where the level of automation is reaching new and new horizons), infrastructure projects still often involve many manual tasks and require special knowledge and specialists, especially given today’s requirements for fault tolerance, flexibility, scalability and elasticity.

Cloud services have been very successful in meeting these requirements, and they have given significant impetus to the development of the IaC approach. This is understandable. After all, it was they who made it possible to configure a completely virtual data center: there are no physical servers, racks, network components, the entire infrastructure can be described using scripts and configuration files.

So what is the difference between GitOps and IaC? It was with this question that I began my investigation. After talking with colleagues, I was able to work out the following comparison:

In other words, GitOps was born precisely because of the application of IaC principles. First, the infrastructure and configurations could now be stored just like applications. The code is easy to store, easy to share, compare, and use versioning capabilities. Versions, branches, history. And all this in a place publicly available to the entire team. Therefore, the use of version control systems has become a completely natural development. In particular, git is the most popular.

On the other hand, it became possible to automate infrastructure management processes. Now it can be done faster, more reliably and cheaper. Moreover, the principles of CI / CD were already known and popular among software developers. It was only necessary to transfer and apply already known knowledge and skills to a new field. These practices, however, went beyond the standard definition of Infrastructure as code, hence the concept of GitOps.

The curiosity of GitOps, of course, is that it is not a product, plugin, or platform associated with any vendor. It is more of a paradigm and set of principles, similar to another term familiar to us: DevOps.

At GitLab, we have developed two definitions for this new term: theoretical and practical. Let’s start with a theoretical one:

GitOps is a methodology that takes advanced DevOps principles used for application development such as version control, interoperability, reconciliation, CI / CD, and applies them to solve infrastructure management automation tasks.

All GitOps processes work using existing tools. All infrastructure code is stored in the familiar git repository, changes go through the same approval process as any other program code, and the rollout process is automated, which minimizes human error, increases reliability and reproducibility.

From a practical point of view, we describe GitOps as follows:

GitOps = IaC MRs CI / CD

We have already discussed infrastructure as code as one of the key components of this formula. Let’s introduce the rest of the participants.

Merge Request (alternative name for Pull Request). In terms of the process, MR is a request to apply code changes and then merge branches. But in terms of the tools we use, this is rather an opportunity to get a complete picture of all the changes that are being made: not only the code diff collected from a certain number of commits, but also the context, test results, and the final expected result. If we are talking about infrastructure code, then we are interested in exactly how the infrastructure will change, how many new resources will be added or removed, changed. Preferably in some more convenient and readable format. In the case of cloud providers, it would be nice to know the financial implications of this change.

But MR is also a means of collaboration, interaction, communication. This is where the system of checks and balances comes into play. From simple comments to formal endorsements and approvals.

Well, and the last component: CI / CD, as we already know, makes it possible to automate the process of making infrastructure changes, testing (from simple syntax checking to more complex static code analysis). And also in the subsequent detection of drift: the differences between the real and the desired state of the system. For example, as a result of unauthorized manual changes or system failure.

Yes, the term GitOps does not introduce us to anything completely new, does not reinvent the wheel, but only applies the already accumulated experience in a new field. But this is its strength.