GitOps is a set of practices for managing infrastructure and application configuration. It leverages Git, an open source version control system that is commonly used in software development projects.
GitOps builds on infrastructure as code (IaC) technologies, which can take a configuration file specifying a desired state of the infrastructure, and automatically bring the infrastructure to that state. This is called declarative configuration. With GitOps, the Git repository becomes a source of truth for all declarative configurations.
GitOps automatically manages infrastructure provisioning and deployment using Git pull requests. Git repositories contain the entire system state, so you can view and review the tracking of system state changes.
GitOps builds on the developer's experience and empowers teams to manage their infrastructure using the same tools and processes as software development. It is not only based on Git, but also integrates with other technologies in the continuous integration / continuous delivery (CI/CD) and cloud native toolset.
In this article:
Here are three main principles of the GitOps pattern.
In the GitOps model, the entire system is configured declaratively. This declarative approach focuses on the outcome (the desired state) rather than the steps required to achieve the desired outcome.
This declarative approach allows the user to specify the ultimate goal without having to worry about all the necessary steps—known as an imperative approach. GitOps creates state-aware declarative configurations, allowing users to store these states in Git for easy deployment and rollback.
All declarative states are stored in a Git repository as the only source of truth. This versioning method makes all system infrastructure changes available in chronological order, allowing users to easily identify infrastructure changes over time. This makes it much easier to perform rollbacks, troubleshooting of failed deployments, and auditing for compliance and security.
When a pull or merge request is made, all changes are stored in Git, so they are verified and approved. In a GitOps model, it is best to immediately and automatically deploy any approved changes. This allows the system to achieve the desired state quickly. It also ensures that the current version of Git configuration matches the actual infrastructure at all times.
GitOps is based on pull requests. When a pull request is initialized, users can see an overview of changes in each repository-based branch. Users can then add a summary of proposed changes, view proposed changes, add tags, and mention other contributors.
After developers create a pull request, they can add a commit in the topic branch. This allows all contributors to see the actual proposed changes. Once everyone approves the changes, they can be merged with the pull request.
Which configuration changes can be included in a pull request?
A GotOps pull request can include configuration changes such as:
After a pull request is approved and the changes are deployed, if there are any problems, troubleshooting is simple. With GitOps, any problem in an environment can be tracked to specific pull requests, and then troubleshooting can focus on the changes introduced in those pull requests.
Integration with other systems
GitOps can also use other tools for Git push, development, and continuous integration:
Organizations adopting GitOps are looking to be on the cutting edge of agile development practices. GitOps provides the following benefits over existing development processes:
GitOps and DevOps approach the development process from two different perspectives:
Here are a few more aspects that set DevOps and GitOps apart.
Imperative and declarative configurations
Monolithic vs. microservices
Can they work together?
Deployment strategies are techniques developers can use to modify or update applications with minimal downtime. GitOps makes it much easier to implement deployment strategies in a consistent manner. Here are some of the most common deployment strategies.
A rolling deployment replaces instances of an application with a new version gradually. It updates some pods, performs a readiness check, and when they are confirmed to be working, shuts down older instances. This means that in case of major issues, a rolling update can be aborted, new instances are terminated and replaced by the current version.
A canary deployment is a type of rolling strategy. It involves introducing a new version for a small subset of application users and observing their behavior, for a period of time that can span from minutes to several weeks. If users respond well to the change, it is rolled out to additional users, until the new version replaces the old.
Related content: Read our guide to canary deployments (coming soon)
In a blue-green deployment, developers run two versions of an application in parallel. Using a load balancer or service routing, they gradually transition traffic from the current production version (green) to the new version (blue). At this point it is still possible to rollback to the old version by rerouting traffic from blue to green.
When the blue version is confirmed to be working well, the production route is reconfigured to point to it, and it becomes the new production version. The old green deployment is then shut down.
An A/B deployment is similar to a blue-green deployment, in that it also runs two versions of the application in parallel. However, unlike blue-green, it defines a percentage of traffic that should go to each version—for example, 50/50 or 20/80—and diverts traffic based on this rule. Over time, when there is more confidence in the new version, the percentage of traffic diverted to it can be increased.
This method is often used to experiment with different versions of the user experience. In other words, both versions run the same back end but with a small variation in the user interface, and development teams can observe differences in metrics like user engagement and conversion.
Here are a few best practices you can use to improve your GitOps implementation.
for up to 20 instances