GitOps: Difference Between GitOps vs. DevOps

With the ever-increasing cloud-native adoption, we see a lot of new concepts that help organizations to build and deliver high-quality software with speed. One such new emerging concept is GitOps, which employs DevOps best practices and enables us to interact with our production servers via simple git commands. GitOps is a new approach to managing software changes. It’s a self-service model with increased automation and transparency for developers and operators. GitOps also helps teams to be more efficient and productive by reducing the time they spend on manual tasks that can be automated or streamlined through automation via Git.

In this article, we will discuss GitOps, how it works, the difference between  GitOps and DevOps in detail.

What is GitOps?

GitOps is a process of implementing continuous deployment for cloud-based applications, especially when it comes to Kubernetes deployments. GitOps emphasizes and boosts a developer-centric experience when operating environment by using the simple tools used by developers, which mainly includes Git and continuous deployment tools such as Flux CD and Argo CD, etc.

Some of the common tools of GitOps other than Git are Flux CD, Jenkins X, ArgoCD, Gitkube, Helm Operator, Quay, and ETC. GitOps is fundamentally a distributed version control system that helps developers with doing Infrastructure as Code (IaC) the right way. It maintains source code and contains text, certificates, and configuration files. Git is the tool used here to manage all these files, configurations and collaborate with various team members.

The main prerequisites of GitOps is to have,

• A Git repository containing declarative specifications of the infrastructure expected in the production environment.
• An Infrastructure as Code ( IaC) approach; an automated process to match the production environment with the defined state in the repository.

When you deploy a new or update an existing application, you should only update the repository, and other processes will be taken care of by the automated process.

The main principles of GitOps are,

• Git is considered as the only single source of truth in GitOps.
• GitOps puts a Git repository at the core of the infrastructure declarations to manage the different states of the application infrastructure.
• GitOps is nothing but Infrastructure as Code done right with current state and desired state approaches. 
• GitOps works on push and pull-based strategies. 
• The current state of a production environment is represented by the Git repository.
• Git stores the state of the application and helps you track each change made and it is important to understand the health of the application.
• Git operations such as creating a commit, fetching, or opening a pull request, etc help developers to modify the state of the application.
• Git flow regulates the deployment, test, and rollback.
• The state of the cluster should match the defined state in the Git repository, once you change the Git state.
• GitOps does not support hand-rolled deployments, ad-hoc cluster changes, and live configuration changes. If anybody wants any change, it must be committed to Git first.

GitOps applies DevOps practices, like version control and continuous integration/continuous delivery (CI/CD), to automate the infrastructure. You can use git and CI/CD tools to replicate and roll back environments to previous versions from the repository.  

How GitOps works?

The idea behind GitHub is very straightforward – use infrastructure as code for all the scripts that you need to create, update or delete your infrastructure. For this, you can use several tools such as terraform, pulumi, and even YAML, to name a few. You save everything in git – your infrastructure files, application files, state of the infrastructure; everything goes in git. Then we automate everything – deployment of apps gets automated, updating the infrastructure gets automated. We can use any of the tools that are available to us and then, we have automation that triggers all of our scripts. 

Let’s see an example of how GitOps works; When you create a Kubernetes deployment file that includes a single replica that will run a container in our Kubernetes cluster. We take this resource definition and commit the deployment definition in Git, and as soon as the changes are committed to git, the automation is triggered to deploy the changes to our Kubernetes cluster. Usually, we have two choices; we can either push a change or cluster can pull the changes. In GitOps, we typically have a pull-based operator that watches the state of infrastructure and applies those changes. This executes kubectl apply, and the app is deployed in Kubernetes. An operator is where you write the logic, and it extends the Kubernetes functionality. 

GitOps strategies

Push-based deployment strategy

The push-based deployment strategy is executed by the CI/CD tools like Jenkins, CircleCI, or Travis CI, etc. The source code of the application is present in the application repository along with the Kubernetes YAML required to deploy the application. 

Image credits: GitOps.tech 

When you update the application code, it triggers the build pipeline and builds the container images, then the environment configuration repository is updated with the new deployment descriptors. When this repository is updated, it triggers the deployment pipeline. This pipeline provides the requirements in the environment configuration repository to the organization. In this approach, you must provide credentials to the deployment environment. 

When you run automated provisioning of cloud infrastructure, the push-based deployment strategy is expected. In this condition, you can use the fine-granular configurable authorization system of the cloud provider for more restrictive deployment permissions.

In the push-based GitOps strategy, when the environment repository changes, the deployment pipeline gets triggered. Thus, it requires a method to monitor, such that you can interfere if the environment does not match the environment repository.

Pull-based deployment strategy

In the pull-based GitOps strategy, there will be involvement of an external event that triggers the CI/CD pipeline. For instance, when a new code is pushed to an application repository.

Image credits: GitOps.tech 

The operator is required for the pull-based deployment approach. The operator compares and analyzes the desired state in the environment repository with the actual state in the deployed infrastructure. If there are any disparities, it updates and renews the infrastructure to match the environment repository. The image registry can also be checked to see and recognize new versions of images to deploy. When there is a change in the environment repository, the pull-based deployment strategy updates the environment. 

The operator must be in the same environment as the application for deployment. In this case, the credentials are not required to be known by the external services. Role-based access control (RBAC) and identity mechanisms can be used for performing deployments, giving the required access and permissions to only authorized personnel keeping security in mind.

Difference between GitOps and DevOps

GitOps is a new cloud-native methodology that needs to mature with more solid use cases and companies adopting it. It is still very early for us all to judge its future. Still, it is already getting good appreciation in the cloud community since it uses the tool that every developer already knows, Git. As Kubernetes-based applications and deployments increase, GitOps proves to be a go-to approach.