An Overview of GitOps

Introducing GitOps

The way systems are developed, delivered, and operated has significantly changed as traditional practices have shifted towards a modern cloud-native approach. This transition has allowed teams to achieve new degrees of agility, scalability, and resiliency in their software. However, it introduces new levels of complexity when managing these systems.

So, what are these complexities? Here are a few examples:

• The delivering system changes at a much faster pace.

• Applications have become an aggregate of distributed components.

• Containerized workloads are now the preferred method to deploy and run software.

• System infrastructure can be rapidly created and destroyed in the cloud.

GitOps is a new way of working which manages the complexity that modern systems introduce into the ongoing development, deployment, and operational phases of a system’s life cycle. It enables software development and operation teams to realize the benefits of a cloud-native approach without experiencing disruptions that sacrifice the stability of their systems.

An extension of DevOps

At a high level, GitOps can be considered the next evolution of DevOps. DevOps allows software delivery at a faster pace by integrating the work of development and operation teams. It does this by aligning the principles, practices, and tools these teams use to manage software delivery.

• Principles: Establish a culture around principles that promote collaboration, continuous improvement, and automation.

• Practices: Adopt processes and ways of working that embrace the organization’s principles.

• Tools: Select tool sets to aid and automate the execution of the established practices.

GitOps overlays additional principles centered around version control on top of an organization’s approach to DevOps. For most teams, version control is synonymous with Git. However, in theory, it could be any version control system you choose. At their foundation, these principles prescribe that every system change must first be committed within Git. Then, the system change is automatically applied to the system from Git.

This approach shouldn’t sound unfamiliar to software development teams that have established pipelines for continuous integration (CI) and continuous delivery (CD). However, in GitOps, it’s expanded to all system changes, including those that alter a system’s infrastructure.

GitOps operational model

When these principles are applied, it results in a system with all the code and configuration (along with a history of changes to them) stored within a Git repository. This repository also serves as the only entry point for introducing a change to the system, producing a complete blueprint for what the system should look like at runtime. Specialized tools designed for GitOps can use this blueprint to provision the system and ensure that its runtime state doesn’t deviate from the blueprint.

The goal of GitOps is to manage an entire system via Git. However, the extent to which these principles are applied and the approach will vary across organizations, teams, and projects. For example, some systems may contain configurations that a GitOps approach can't manage due to historical decisions made regarding its technology stack. Alternatively, the GitOps toolset chosen by one organization may be completely different from other organizations, causing their approaches to be drastically different. It’s important to keep these points in mind when dealing with GitOps, recognizing it as a general model for managing system operations in which actual implementations will vary. There is not one-size-fits-all approach to putting GitOps into practice.

Adopting GitOps principles improves how teams deliver and operate complex distributed systems that run on elastic infrastructure. For teams to successfully operate systems with GitOps, a strong understanding of the GitOps principles, common GitOps practices, and the tools that support it are required.