What is GitOps?

GitOps is a methodology that relies on storing the desired state of the application and infrastructure as code in Git and then using an automation tool to apply those changes to the target environment. GitOps provides an operational framework for DevOps teams and architects to automate the deployment and management of applications in a repeatable, reliable way. The GitOps process will have three essential characteristics:

Git (GitHub, GitLab, BitBucket) is a source of truth. Every code change to the application or infrastructure should be checked into the Git repository.
A CI/CD pipeline can invoke the GitOps process to automatically deliver reviewed and merged changes in the target Kubernetes cluster.
A monitoring process should automatically detect the difference between a desired state in Git and the target cluster and reconcile any differences between them.

GitOps methodology is helpful for application developers to deploy their changes continuously and for DevOps teams and architects to perform Kubernetes cluster management.

5 Fundamental GitOps Principles

The term GitOps was coined by Weavework in 2016. Since then, the methodology has been adopted by various software delivery teams in larger enterprises and startups across the globe. After interacting with many GitOps users, there are five fundamental principles for successfully adopting GitOps.

Express the desired state declaratively

The first step to practicing GitOps is to ensure everything from application to infrastructure to configurations is stored declaratively. This practice of expressing everything declaratively is known as infrastructure as code (IAC). One example is the Kubernetes manifest file to create several instances of an application instead of manually starting the infrastructure and configuration. The declarative infrastructure enables GitOps, as it empowers developers to self-serve what they need through code and accelerate continuous delivery.

Version control the desired state

Store all the declarative files for your preferred form of apps, infrastructure, and configuration in the version control system like GitHub or GitLab. Since the immutable code is versioned in the Git repository during every code change, developers can see the history of all the changes made to the source code. This also helps to roll back into a previous working state using ‘Git revert’ in case of any error.

Automatically apply the desired state to the system

When new code changes are merged in the configuration after approval, it should be automatically applied to the target cluster. A software agent like the Argo CD application controller already deployed in the cluster monitors the repo at regular intervals. Once it detects any change, the controller automatically pulls the latest Git state and applies it to the system.

Reconcile the desired state in case of configuration drift

The agents that pull the desired state into the system should constantly monitor the Git repo and the cluster. So whenever an unintended change (say a developer misconfigured a cluster accidentally), the target cluster can self-heal and reconcile the desired state as declared in Git.

Visibility and control

Since GitOps will be used to frequently deploy the code into multiple clusters, there should be a proper mechanism to view deployment details. GitOps visibility tools can help understand all the applications deployed into numerous clouds and clusters, along with their health and deployment status. Secondly, you should also have security functionality such as RBAC to allow the team to participate in the GitOp process with the least privilege.

How does GitOps work?

GitOps workflow begins by deploying GitOps engines like Argo CD or Flux CD in the target Kubernetes cluster. They are configured with the credentials to access (read-only) the Git/GitOps repository, where application deployment specifications for the cluster are stored.

Developers commit changes to the application source code repository and open up a pull request. Once it is reviewed and merged, it will trigger the CI pipeline or build tool, like Jenkins. Jenkins will test the changes, build a container image, and store it in an image registry such as Docker Hub. A continuous delivery pipeline can be initiated to update the manifest files in the Git repo with the latest image version and invoke the GitOps process in Argo. The CD pipeline can be used to automate other stages, such as testing or manual judgment, etc.

Argo CD will continuously monitor the changes in Git. When it detects changes, Argo CD will automatically pull the updated manifest files/desired state and apply them against the cluster. Argo CD will continue to monitor both the Git repo and the cluster, ensuring that the cluster always remains in sync with the intended configuration. If any drift is detected, it will automatically reconcile the cluster state by applying any necessary changes.

The significant difference GitOps workflow has with the traditional CI/CD pipeline is how the deployment pipeline (CD part) works. While the conventional CI/CD pipeline requires manual intervention to trigger the pipeline for deployment, GitOps tools are used for continuously deploying into Kubernetes clusters whenever a change is detected.

Top 3 open-source GitOps tools

1. Argo CD: A go-to GitOps tool for the majority of DevOps and Platform teams, Argo CD serves as a declarative continuous delivery tool for Kubernetes applications. Argo CD is easy for beginners to get started with GitOps because of its user-friendly UI, which makes it easier to monitor and manage the state of their K8s clusters.

The Argo project consists of four products: Argo CD, Argo Workflow, Argo Rollouts, and Argo Events. Each product is designed to address specific challenges in the agile development process and help organizations scale and secure their Kubernetes application delivery.

2. Flux CD: Weaveworks created Flux CD, and it employs a CLI-first approach to GitOps-style deployments into K8s clusters. Like Argo, Flux is also a Cloud Native Computing Foundation (CNCF) Graduated project. However, the lack of a centralized UI for monitoring and managing deployments across multiple clusters and environments might make it less appealing for some organizations.

3. Jenkins X: Unlike Argo and Flux, Jenkins X is a complete Kubernetes-native CI/CD engine built around GitOps. The scope of Jenkins X stretches beyond GitOps-style continuous delivery, as it can run full CI/CD pipelines through its integration with a variety of tools. However, the broad range of features and tools can make it difficult for some teams, given the complexity and steep learning curve to set it up and manage.

Looking at the above tools, it becomes clear that Architects or DevOps teams better choose Argo or Flux if the requirement confines to GitOps-style continuous delivery. If it is difficult to choose between Argo and Flux, we have written an in-depth article that will help: Argo CD vs Flux CD: Best tools for GitOps.

Benefits of using GitOps

Improved developer experience (DX): Git as a collaboration tool, andInfrastructure as Code (IaC) helps developers self-serve required infrastructure without waiting for the DevOps team. This improves DX and productivity, as they can experiment and iterate quickly without delays in the delivery process.

Faster deployments and quick feedback: GitOps ensures that new features and bug fixes have reduced time-to-market, allowing end users to receive updates at the earliest. It allows for a faster feedback loop that fosters experimentation, better product updates, and improves customer satisfaction.

Transparent change management and audit trail: Developers create pull requests (PRs) in Git whenever a code change occurs. PRs have timestamps, along with the record of participants involved in the change, such as authors, reviewers, and approvers. This provides visibility while auditing the modifications done to the infrastructure and improves the audit process.

Zero downtime with instant rollback: Since all the configurations are stored and versioned in Git, the application can be rolled back to the previous version instantaneously without causing unnecessary service unavailability.

3X improved manageability: By keeping an application, infrastructure, deployments, network and security policies in a single place, the manageability of all the resources increases by many folds.

GitOps and DevOps

There is always a debate in the community around GitOps vs DevOps. Before putting our stand on it, let us consider what each means.

DevOps is a philosophy that shifted a paradigm to software development by breaking silos between development (Dev) and operations (Ops). DevOps advocated and shortened the application development lifecycle, helping organizations release incremental changes rapidly and frequently and improving collaboration through constant feedback. GitOps, on the other hand, is a form of continuous deployment that relies heavily on Git and IaC.

We believe there is only “GitOps and DevOps,” not “GitOps vs DevOps”. Both philosophies complement each other and allow enterprises to improve software delivery through collaboration and automation of the entire SDLC.