The GitOps Guide: Principles, Examples, Tools & Best Practices

What Is GitOps?

GitOps is a paradigm or a set of practices that empowers developers to perform tasks typically done by IT operations. It uses tools familiar to developers, leveraging the power of Git as a single source of truth for declarative infrastructure and applications. With Git at the center of your delivery pipelines, developers can make pull requests to accelerate and simplify application deployments and operations tasks to Kubernetes.

GitOps is more than just “infrastructure as code” or “Git push to deploy.” It’s about a set of practices to manage infrastructure and application configurations using Git. These practices are designed to create an environment where complete system state is versioned and automated, providing speed, reliability, and security for your software development lifecycle.

This is part of an extensive series of guides about software development.

In this article:

What Is the Difference Between GitOps and DevOps?

GitOps is a natural progression in the DevOps journey. DevOps is a cultural movement that promotes the collaboration between software developers (Dev) and IT operations (Ops) to deliver software faster and more reliably. It is about breaking down silos and encouraging cross-functional teams to work together. DevOps focuses on practices like continuous integration, continuous delivery, and infrastructure as code.

GitOps takes these principles and further optimizes them for cloud-native environments. GitOps uses Git as a single source of truth for both development and operations. It leverages the pull request mechanism of Git to manage all changes to the system. GitOps brings a level of standardization and automation to the process, making it more efficient and less error-prone than traditional DevOps.

Learn more in our detailed guide to GitOps vs DevOps

3 Principles of GitOps

1. Declarative System

The first principle of GitOps is having a declarative system. This means operators define the desired state, and it’s the system’s responsibility to achieve that state. This is in contrast to an imperative system where the operator provides specific commands to reach the desired state. With GitOps, you declare what you want, and the system makes it happen.

2. System State Captured in a Git Repository

The second principle of GitOps is that the entire system state is captured in a Git repository (this is the “Git” in GitOps). Having the entire system state in Git means that you have a version-controlled history of all changes. It also means that you can easily revert to a previous state if something goes wrong. This makes managing complex systems much more manageable.

3. Automatic Deployment

The third principle of GitOps is automatic deployment. Changes to the system state are automatically applied to the system. This is done using Git’s pull request mechanism. When a pull request is merged, the new state is automatically deployed to the system. This makes deployments fast, reliable, and repeatable.

Tips From the Expert

In my experience, here are tips that can help you better implement and optimize GitOps practices:

Use Git tags to mark significant deployments Tagging commits with specific deployment milestones (e.g., v1.0.0-prod) provides clear references for when major versions or stable releases were deployed. This simplifies rollbacks and historical tracking, especially in complex environments with multiple concurrent releases.
Integrate automatic drift detection Implement tools that continuously monitor the state of your production environment against the desired state defined in Git. This helps ensure system consistency and alerts you when changes occur outside the GitOps pipeline, enabling quick remediation of configuration drift.
Enforce code reviews for infrastructure changes Treat infrastructure code with the same rigor as application code. Require pull requests for all changes and conduct formal code reviews to ensure that infrastructure modifications follow security and compliance guidelines. This reduces the risk of misconfigurations that could compromise production.
Adopt environment-based branching strategies Structure your repositories to separate environment-specific configurations (e.g., main, staging, production branches). This approach enables safe testing and validation in non-production environments before changes are merged into production, reducing deployment risks.
Employ Git submodules for complex multi-repo setups If your project spans multiple repositories (e.g., microservices with independent deployment pipelines), Git submodules or monorepos can help keep shared infrastructure components synchronized while maintaining separation between application-specific configurations.

Ran Cohen

CTO & Co-Founder. Configu

Before co-founding Configu, Ran was a full stack developer at Testim.io and previously served in an elite cybersecurity unit in the Israeli Defense Forces.

What Are the Benefits of GitOps?

Here are a few reasons GitOps is rapidly growing in use among development teams:

Increased productivity: By automating deployments and managing system state with Git, developers can focus on coding instead of manual deployment tasks. This not only speeds up the development process but also reduces the risk of human error.
Reliability and security: By having the entire system state version-controlled in Git, you can easily track all changes and revert to a previous state if necessary. This makes it much easier to identify and fix issues. There are also fewer manual processes that could introduce errors or security vulnerabilities.
Standardized workflows: In a GitOps process, everything is managed through Git, from application code to infrastructure, configurations, and deployments. This brings a new level of consistency and predictability to your software development process.
A single set of tools: With GitOps, Git is used for version control, collaboration, and managing system state. The same pull request mechanism used for code reviews is also used for infrastructure changes and deployments. This not only simplifies the process but also makes it more efficient, as there is no need to switch between different tools.

GitOps Use Cases

Here are some of the common use cases of GitOps in development organizations.

GitOps for Developers

As a developer, GitOps provides a consistent and auditable version control system. Each change is tracked, enabling easy rollbacks if necessary, and the state of the system can be clearly seen at any stage.

GitOps allows developers to work in an environment that mirrors the production setup. This eliminates the “it works on my machine” problem as developers and operations teams are now on the same page.

Moreover, the pull request workflow familiar to developers is extended to operations. This creates a clear process for making and reviewing changes, fostering collaboration and communication within the team. In essence, GitOps empowers developers to take control of their deployment process, enabling them to iterate faster and with greater confidence.

GitOps for Platform Engineers

For platform engineers, GitOps is a game changer. The use of Git as a single source of truth eliminates the need for manual configuration and the associated human error. Instead, everything is stored in version-controlled repositories, leading to enhanced security and traceability.

GitOps also brings a level of automation that significantly reduces the operational burden. The system automatically corrects any drift from the desired state, freeing up engineers to focus on more strategic tasks

Finally, GitOps supports a culture of continuous improvement. The ability to easily try, test, and roll back changes encourages experimentation and innovation. It enables platform engineers to continually refine and optimize the system for better performance and reliability.

GitOps for Kubernetes and Cloud Native

The cloud native world is complex and fast-evolving. To thrive in this environment, organizations need tools that can manage this complexity and speed up the pace of delivery. This is where GitOps comes in.

GitOps leverages the declarative nature of Kubernetes, allowing the desired state of the system to be defined in code. This makes it easy to manage even complex, multi-cloud environments.

Moreover, GitOps accelerates the deployment process. Changes are automatically rolled out once they are merged into the Git repository, reducing lead times and enabling continuous delivery. In addition, GitOps enhances the observability of the system. By aligning the actual and desired state of the system, GitOps provides a clear view of what is happening at any given moment. This supports faster troubleshooting and more proactive management of the system.

Learn more in our detailed guide to GitOps Kubernetes (coming soon)

GitOps for Teams Adopting Continuous Deployment

For teams adopting continuous deployment, GitOps can play a pivotal role. By automating the deployment process, GitOps reduces the risk of human error and accelerates the pace of delivery.

Moreover, the transparency provided by GitOps fosters trust and accountability within the team. Everyone can see who made what change and when, and the impact of those changes on the system. This visibility is critical for high-performing teams aiming for continuous deployment.

An Example of a GitOps Workflow

Step 1: Developers Commits Changes to Code in the Git Repository

When a developer makes changes to the application code, these changes are committed to a Git repository. This involves updating the codebase with new features, bug fixes, or other modifications. The developer then pushes these changes to a remote repository, triggering the next steps in the GitOps workflow.

This process ensures that all changes are version-controlled and that there is a comprehensive history of the code evolution, aiding in tracking and rollback if needed.

Step 2: A Second Git Repository Holds the Deployment Configuration for the Application

Alongside the code repository, there’s a second Git repository dedicated to holding the deployment configuration. This repository contains files that describe the desired state of the application in the production environment, such as Kubernetes manifests or Docker-compose files.

By separating code from configuration, GitOps enforces a clear distinction between what the application does (code) and how it runs (configuration). This approach simplifies managing and updating the system’s operational aspects.

Step 3: Changes to the Git Repository Are Monitored by the GitOps Agent

A GitOps agent is a piece of software that continually monitors the configuration repository for any changes. Tools like Argo CD are commonly used for this purpose. When a change is detected—like a new commit or a merged pull request—the agent compares the current state of the deployment environment with the desired state defined in the repository. If a discrepancy is found, the agent initiates the process to align the environment with the desired state.

Step 4: Changes Are Rolled Out to the Staging or Production Environment

When changes are detected, the GitOps agent initiates an automated deployment process. This typically involves generating a new container image and deploying it to the appropriate environment, which could be a staging or production environment.

This automation ensures that the deployment process is consistent and repeatable, reducing the chances of human error and speeding up the deployment cycle.

Step 5: When Deployment Completes, Developers Test the Application

After the deployment is complete, the changes are live in the target environment. Developers can then perform post-deployment tests to verify that the application behaves as expected in the real-world setting.

This step is crucial for ensuring the quality and reliability of the application. Any issues discovered at this stage can be quickly addressed by making changes to the code or configuration, which then restarts the GitOps workflow. Alternatively, it is easy to roll back to a previous stable version.

5 Notable GitOps Tools

1. ArgoCD

ArgoCD is an open source tool managed by the cloud native computing foundation (CNCF). It is a declarative, GitOps continuous delivery tool designed for Kubernetes. ArgoCD automates the deployment process by synchronizing applications with the defined states in Git, ensuring consistency and reliability in deployment pipelines.

A key feature of ArgoCD is its ability to provide a real-time, visual representation of application states, making it easier for teams to monitor and troubleshoot deployments. It integrates with popular CI systems and supports multiple configuration management tools.

Additionally, ArgoCD facilitates rollbacks by keeping track of all changes and versions, allowing for quick restoration to previous states. Its robust access control and security features ensure that only authorized changes are deployed, maintaining the integrity of the production environment.

2. Flux CD

Flux CD is an open source GitOps tool developed by Weaveworks, which specializes in continuous and automated deployment of applications to Kubernetes clusters. It continuously monitors Git repositories for changes and applies them automatically to the Kubernetes cluster, streamlining deployment processes. One of its notable features is its ability to handle multi-tenancy efficiently, allowing different teams to manage their resources independently within the same cluster.

Flux supports a range of Kubernetes resources and is capable of handling complex deployment scenarios. It also offers features like automated container image updates, where it can track container image registries and automatically update the Kubernetes manifests with new image versions.

The integration of Flux with Helm, a package manager for Kubernetes, allows for easy management of Helm charts via Git repositories, further simplifying deployment workflows. Security in Flux is given due attention, with its support for signing and verifying Git commits, ensuring that only verified changes are deployed.

3. Codefresh

Codefresh is a modern CI/CD platform designed primarily for Kubernetes, offering a unique blend of traditional continuous integration and GitOps practices. Codefresh is known for its user-friendly interface that simplifies the build, test, and deployment processes. It offers a scalable build infrastructure, capable of handling multiple concurrent builds efficiently.

Codefresh integrates seamlessly with various version control systems, container registries, and Kubernetes clusters, providing a comprehensive environment for end-to-end application delivery.

One of the key features of Codefresh is its ability to create dynamic, disposable environments for each code branch or pull request, enabling developers to test changes in isolation before merging them into the main branch. This feature significantly enhances the code review process and improves the overall quality of the software.

Codefresh also offers a rich set of plugins and integrations, allowing teams to extend its capabilities and tailor it to their specific workflows. The platform includes advanced debugging tools and detailed logs, helpful for identifying and resolving issues in the CI/CD pipeline.

4. Weaveworks

Weaveworks, which originally coined the term ‘GitOps’, offers a comprehensive set of tools to implement GitOps workflows, especially in Kubernetes environments. The Weaveworks platform provides a full-stack solution for cloud-native applications, covering deployment, monitoring, and management. A significant feature of Weaveworks is its orchestration and automation capabilities, which allow for efficient management of containerized applications and microservices.

The tool integrates with Kubernetes, enabling seamless application deployments, scaling, and management directly from Git repositories. Weaveworks also emphasizes observability and monitoring, providing detailed insights into the performance and health of applications and infrastructure.

The platform supports a range of cloud providers and infrastructure components, making it versatile for different deployment scenarios. Additionally, Weaveworks places a strong emphasis on security, ensuring that only authorized changes are applied to the infrastructure, and incorporates features for disaster recovery and compliance.

5. Jenkins X

Jenkins X is an open-source CI/CD solution for cloud-native applications on Kubernetes. It extends the traditional Jenkins CI/CD pipeline model with features specifically designed for Kubernetes. Jenkins X automates the setup of pipelines, environments, and deployments, significantly reducing the manual effort required in managing CI/CD processes.

One of the key features of Jenkins X is its environment promotion strategy, where it automatically promotes builds through different environments based on GitOps principles. It also supports preview environments, allowing developers to preview changes in a real environment before merging them.

Jenkins X integrates with major cloud providers, offering native Kubernetes support and simplifying the deployment of cloud-native applications. The tool also includes built-in support for Helm, making it easier to manage and deploy Helm charts.

Learn more in our detailed guide to GitOps tools (coming soon)

GitOps Best Practices

Here are some best practices to ensure a successful GitOps implementation.

Plan Branching Strategies

The branching strategy you adopt can significantly impact your team’s productivity and the overall quality of your code. This strategy is a set of rules: a convention that describes when to branch, what to do with the branch, and when to merge it back.

There are several branching strategies you can adopt depending on your team’s needs. GitFlow, for instance, is a popular choice. It involves creating a develop branch for integrating features, a master branch for releases, and separate branches for hotfixes and releases.

Avoid Mixed Environments

A mixed environment is a setup where the application code and the infrastructure code reside in the same repository. This is a common setup, especially for smaller projects, but it can lead to complications as the project grows.

The problem with mixed environments is that they can lead to dependencies between the application code and the infrastructure code. This can cause conflicts when changes are made, making it difficult to manage and maintain the code.

Instead, it’s recommended to separate the application code from the infrastructure code. This way, changes in one do not directly affect the other. This separation also makes it easier to manage changes and rollbacks, as each component can be versioned and managed independently.

Encourage Merge Request Discussions

Merge requests, also known as pull requests in GitHub, are a crucial part of any GitOps workflow. They provide a platform for code review and discussion before changes are merged into the main branch.

Merge request discussions are a best practice in GitOps. They enable a collaborative approach to code review, where team members can comment on the proposed changes, ask questions, suggest improvements, or even request changes before the code is merged.

This practice not only improves the quality of the code but also fosters a culture of collaboration and continuous learning within the team. It’s a way to share knowledge, learn from each other, and continuously improve your codebase.

Policy as Code

Policy as code is a practice where policy definitions are written in code and stored in version control, just like application and infrastructure code. Policies are typically used to apply security or compliance conventions across software projects. A policy as code approach allows for versioning, automated testing, and automated deployment of policies, like any other code.

Policy as code is crucial in GitOps as it allows for consistency and repeatability. Since policies are defined in code, they can be consistently applied across different environments. It also allows for transparency. Since policies are stored in version control, they are visible to all team members, and any changes to the policies are tracked. Finally, it allows for automation. Since policies are defined in code, they can be automatically enforced through CI/CD pipelines.

Ensure Idempotency

Idempotency means that the result of performing the same operation multiple times is the same as if it were performed only once. In the context of GitOps, idempotency refers to the ability to apply the same operation or code multiple times without changing the result beyond the initial application.

Idempotency plays a crucial role in GitOps, especially in the context of infrastructure as code. It allows you to apply the same configuration multiple times without causing unintended changes or side effects. This is particularly important in a distributed system where multiple processes or threads may try to apply the same configuration at the same time.

Learn more in our detailed guide to GitOps best practices (coming soon)

Supporting GitOps with Configuration Management

Configu is a configuration management platform that streamlines and automates config management, making it better suited for GitOps processes. You can think of Configu as Git for configurations. It’s comprised of two main components:

Configu Orchestrator

As applications become more dynamic and distributed in microservices architectures, configurations are getting more fragmented. They are saved as raw text that is spread across multiple stores, databases, files, git repositories, and third-party tools (a typical company will have five to ten different stores).

The Configu Orchestrator, which is open-source software, is a powerful standalone tool designed to address this challenge by providing configuration orchestration along with Configuration-as-Code (CaC) approach.

Configu Cloud

Configu Cloud is the most innovative store purpose-built for configurations, including environment variables, secrets, and feature flags. It is built based on the Configu configuration-as-code (CaC) approach and can model configurations and wrap them with unique layers, providing collaboration capabilities, visibility into configuration workflows, and security and compliance standardization.

Unlike legacy tools, which treat configurations as unstructured data or key-value pairs, Configu is leading the way with a Configuration-as-Code approach. By modeling configurations, they are treated as first-class citizens in the developers’ code. This makes our solution more robust and reliable and also enables Configu to provide more capabilities, such as visualization, a testing framework, and security abilities.

Learn more about Configu

See Additional Guides on Key Software Development Topics

Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of software development.