GitOps is a new development methodology that allows fluid deployment of Infrastructure as Code (IaC). What is GitOps vs. DevOps, and how is it configured with GitLab?

The world of Infrastructure as Code (IaC) has totally revolutionized the way infrastructure is provisioned, configured, and maintained. Engineers no longer have access to physical servers and network equipment. Rather, they can now provision infrastructure using powerful APIs that allow performing all the necessary tasks using code. This new mindset has brought about a whole new discipline called DevOps.

DevOps was born from the new model of how infrastructure can be controlled with code. However, there is an even newer model that is a subset of the DevOps model, called GitOps. GitOps is now the de facto standard for CI/CD. What is GitOps? Why is this model important? How can version control be used to define the DevOps workflow and synchronization across systems?

Overview of DevOps ^

To begin with, let's take a look at DevOps and what it is, exactly. Is DevOps a tool? No, it does not refer to a particular software or other tool. Instead, DevOps is a combination of things, including the tools that allow businesses to deliver development and applications at a rapid pace, and a new mindset that breaks down the barriers between development and operations. Instead of being two historically very different and separate roles, they are sometimes even merged into a single team where both developers and operations engineers work side-by-side to develop, test, and deploy new applications across the enterprise.

DevOps practices allow organizations to deliver software innovation much faster than with traditional software updates and delivery. This capability is mainly due to the DevOps mindset and processes that provide frequent, small updates. It allows businesses to satisfy their customers' needs more quickly by rapid, incremental software updates instead of massive updates that may only appear once or twice a year. The DevOps model involves a process known as a "feedback loop" that allows businesses to use the following processes in software delivery:

  • Build
  • Test
  • Release
  • Monitor
  • Plan
The DevOps development feedback loop image courtesy of Amazon

The DevOps development feedback loop image courtesy of Amazon

Continuous Integration/Continuous Delivery

There are two essential components to the DevOps development model: continuous integration and continuous delivery (CI/CD). You will often hear the expression "CI/CD pipeline." Continuous integration is the process by which software developers merge their code changes, often into a central code repository. After the merge happens, automated builds are tested and run to ensure the code changes are valid. Continuous delivery describes a similar process where code changes are released to production using automation to control building, testing, and preparing the code for release.

Built on cloud technologies

There is no question that cloud-native technologies have made the DevOps approach and methodology possible. With cloud-native technologies, organizations are now using microservices instead of the traditional monolithic applications of years past. By breaking up applications into smaller components built on containerized technologies, it allows a much more nimble and agile approach to the incremental updates and releases that the DevOps approach embraces.

What is GitOps? ^

There is another term that you may see tossed around today that is quickly gaining momentum—GitOps. Born from the DevOps model, GitOps focuses on the code version control system and declarative implementation of new code versions.

GitOps is centered around a version control system such as Git. However, despite what the name implies, the version control system does not have to be Git. Git is just the most popular version control found among enterprises. Generally speaking, GitOps leverages Git version control. It takes DevOps best practices for application development, including version control, collaboration, compliance, and CI/CD, and applies these to infrastructure automation. It allows taking things like pipelines, infrastructure, code, dependencies, policies, and approvals, and bringing them into a single repository with approvals. Ultimately, the Git repository is the single source of truth in this everything-as-code model.

Similar to how developers use application source code, operations teams adopting the GitOps framework can use configuration files that comprise IaC and allow deploying infrastructure in a declarative manner that is consistent, agile, and maintainable.

The main components of GitOps include the following:

  • IaC—Infrastructure in modern cloud-native environments and even modern on-premises infrastructure can be described using infrastructure configuration or definition files.
  • Merge requests—When developers or operations develop or make code changes, they are merged back into the main branch via a merge request. The merge request provides the opportunity for new code to be reviewed and accepted or rejected. It creates an audit trail and change process that includes the peer reviews needed to ensure the code changes are valid.
  • CI/CD—Infrastructure changes and updates in the GitOps model are automated using the CI/CD process. Once the new merge request is approved, the CI/CD pipeline automatically reacts to the merge and applies the defined changes. Automatic builds help to quash any drift from the desired state described in the Git repository, which is, again, the source of truth.

GitOps with GitLab ^

GitLab provides a platform that can empower teams with the tools and capabilities needed to benefit from the GitOps development model. It serves as the Git repository, merge request, and approval mechanism, and runs CI/CD pipelines to automate builds. Below, let's step through some of the tools and concepts using GitLab to take advantage of GitOps processes.

One of the keys with the GitOps model is using the merge requests to audit and perform code reviews and initiate the CI/CD pipeline once the merge request is approved. To force developers to use merge requests, GitLab relies on the concept of protected branches. These protect the main branch so that merges are the only way code is updated.

Configuring protected branches in GitLab

Configuring protected branches in GitLab

Typically, a developer or GitOps engineer will create a new branch representing new code to merge into the main branch. They will develop the code locally in their local repository and then push the changes to the central code repository in GitLab. Often, organizations choose to name branches based on a ticketing system such as Jira, which captures the functionality enhancement details.

Creating a new branch to make code changes

Creating a new branch to make code changes

After the code has been pushed to the GitLab repository, a merge request is initiated to merge the changes to the main code branch. There are generally reviews and other processes in place that happen before code is merged. Typically a reviewer is placed on the merge request to review the code.

Creating a new merge request for code changes

Creating a new merge request for code changes

Once the code is merged, the GitLab CI/CD pipeline build kicks off. It begins the build process, bringing the dev, test, or production environment into the desired state represented in the repository.

Subscribe to 4sysops newsletter!

CICD pipeline build kicks off after code is merged to the main branch

CICD pipeline build kicks off after code is merged to the main branch

Final thoughts ^

The cloud revolution, IaC, and DevOps have led to a new methodology to deploy applications and infrastructure. The line between development and IT operations is now blurred, with both teams using code to perform tasks. GitOps is the natural evolution of DevOps and allows organizations to use a code repository such as Git as the source of truth. Merge requests are the means by which the audit trail and approvals are established. After the code is merged, the CI/CD pipeline process automatically initiates a build to bring the environment in line with the declarative state represented in the code.


Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account