The Ultimate Manual To GitOps

GitOps has become a popular buzzword and hot topic in the development community in recent years. If you’re interested in learning more about GitOps and how it works, you’ve come to the right place.

What is GitOps Anyway?

GitOps is an operational framework used to manage application configurations and infrastructures with Git—an open-source system for version controls. 

The GitOps practices are all built around the developer experience, making it easier for teams to use tools and processes of their choosing. Beyond Git, these principles allow developers to choose which tools they want to use for application delivery and continuous deployment. 

Infrastructure automation is a primary focus of GitOps. Due to the demands of modern environments, infrastructures must be elastic to accommodate continuous deployments with cloud resources. Operations teams adopt GitOps to automate infrastructure provisioning, so all configuration files generate the same environment with each deployment. 

In simple terms, GitOps defines the process for Git pull requests that validate and automatically deploy changes to system infrastructures. 

How GitOps Works

GitOps is a systems operations (ops) process connected to a specific tool (Git). It uses Git as a single source of truth while using DevOps best practices and infrastructure as code to create, update, and delete system architectures. 

There is no single product, platform, or plugin that defines GitOps. Instead, it’s a workflow that teams can use to manage an IT infrastructure with processes already being used in application development. 

These are the three key components required by GitOps:

• Infrastructure as Code (IAC) — IaC keeps all of the infrastructure configurations stored as code within Git, which is accomplished using a Git repository to hold all infrastructure definitions as a single source of truth. All code management changes made to the project files get stored in a .git folder.
• Merge Requests (MRs) — MRs are used as the change mechanisms for infrastructure updates. This is when teams can use comments, reviews, and formal approvals for collaboration. Merge requests commit the work to the main branch and double as an audit log.
• Continuous Integration and Continuous Delivery (CI/CD) — Whenever new code gets merged, the CI/CD pipeline enables the environment changes. Any errors or manual changes are automatically overridden by GitOps. This ensures that the environment connects with the desired state defined in the Git repository. 

The basic idea of GitOps is that there’s always a Git repository containing descriptions of an infrastructure in the desired production environment. GitOps is designed to automate the production environment to match the state described in that repository.

When developers or organizations want to deploy a new cloud-native application or update an existing one, they simply need to update the repository. Everything else gets handled by the automated process defined by GitOps. 

GitOps vs. DevOps

There’s a significant amount of parallels and overlap between GitOps and DevOps. But these two terms are not interchangeable, and they’re used for different things.

The quick difference—DevOps is a combination of culture, operations, development, and tools, that allow teams to create and improve software at a faster rate. But GitOps is connected to Git and automates infrastructure configurations. 

It’s not mandatory for organizations using a DevOps culture to adopt GitOps. GitOps is not a replacement for DevOps. Instead, GitOps can be used to increase productivity for DevOps teams.

Other key differences between GitOps and DevOps include:

• GitOps is a technique to manage infrastructure provisioning and software deployments, while DevOps is a culture that prioritizes CI/CD.
• GitOps is tied to a specific tool—Git. DevOps is not tied to a specific tool but focuses on the CI/CD pipeline.
• DevOps is not as strict as GitOps.
• DevOps is more open and flexible than GitOps.
• DevOps focuses on automation and frequent deployments, while GitOps focuses on correctness.
• GitOps might use IaC, separate CI/CD, pipelines, and Kubernetes as supplementary tools.
• DevOps might use Cloud Configuration as Code (CaC) and supply chain management.

Due to the similar fundamentals, it’s much easier for teams to adopt GitOps workflows if they’re already using DevOps principles. 

Let’s take a look at some real-world examples to show what GitOps looks like in action.

Example #1: Mettle Case Study With GitOps

Mettle is a UK-based financial technology company. They provide small businesses with an application designed to manage finances and speed up payments. The application helps businesses solve problems related to late payments due to a lack of visibility.

With Mettle, businesses can quickly send customized invoices to clients and connect everything with accounting software. 

According to the case study, Mettle used GitOps to overcome some challenges to keep the application running smoothly. The application must be available 24/7, but the Mettle engineering team needed a way to deploy new features without compromising the platform’s security or usability. 

GitOps made it possible for Mettle to create a self-service platform for their engineers. The team was able to deliver continuous business value using innovation without needing full assistance from the platform team. 

Adopting a GitOps workflow ultimately helped Mettle increase productivity. Now they have clusters that are truly ephemeral. Thanks to GitOps, it’s easy for them to reconcile the current state of a cluster directly from their Git repositories. 

Mettle was even able to create a Bug Bounty program without having to change the CI pipelines. 

Production speed increased by 50%, and deployments increased by 75%. It’s now possible for the team to eliminate a cluster and create a new one within 20 minutes, confidently knowing that the new cluster will be in the same state as the previous one. Developers are less focused on operations, and they can focus more on their own responsibilities. 

Example #2: Slite Case Study With GitOps

Slite is a workplace platform designed for remote teams. While many organizations had been transitioning to remote or hybrid work, Slite was faced with a unique opportunity during the global pandemic. 

This opportunity doubled as a challenge—scalability to meet demand. They needed a way to scale that was sustainable for the future, as opposed to just a short-term fix for an anomaly situation. 

Slite’s case study explains why GitOps was the perfect solution to accommodate these problems.  

Slite’s main product is segmented into roughly 15 microservices that are essentially independent of each other. They run on Kubernetes clusters for production and staging. 

Since the products were already split into different microservices, it was easy to automate and leverage an independent delivery process using GitOps. Slite was already using GitHub Actions for builds and deployment, so they just needed to modify the existing tech stack. 

All of Slite’s source code was already housed in Git as well. They just needed to standardize the change release process for all of the environments to see which versions and configurations were being run. 

As a result of adopting GitOps, Slite now has a fully automated delivery that allows the team to deploy 20 times each day. They’ve also scaled the engineering team from six employees to 16 employees, and bug fixes are in progress within 15 minutes of being identified. 

How to Get Started With GitOps

Getting started with GitOps might seem a bit overwhelming if you’ve never been through this process before. For organizations that are already using DevOps principles, GitOps adoption should be a bit smoother. 

Just follow the steps below to build momentum as you get started implementing GitOps into your workflow. 

Step 1: Embrace the Benefits of GitOps

Understanding what you’re going to get out of GitOps is really helpful during the initial implementation. Educating your team about these benefits and getting everyone on the same page will make your life easier as these practices come to fruition.

Some of the top GitOps benefits include:

• Increased Productivity — Automating CI/CD ultimately speeds up your average time to deployment. GitOps allows your team to ship more daily changes and increases your overall output.
• Improved Developer Experience — Developers can use tools they’re already familiar with to push code. GitOps also makes it possible to onboard new developers and get them up to speed in days as opposed to months.
• Enhanced Stability — Using Git workflows to manage clusters means you have an audit log of who did what and when they did it. This can be used for SOC 2 compliance and enhanced stability. 
• Enhanced Reliability — GitOps makes it possible to fork and revert with ease, meaning the rollbacks are stable and reproducible. You can quickly recover your entire system from a single source of truth, meaning your MTTR (mean time to recover) can drop from hours to minutes. 
• Standardization — Since GitOps offers a single system for your infrastructure, the end-to-end workflow across your entire team and organization is always consistent. This makes it easy to scale operations. 
• Robust Security Standards — The cryptography in Git that manages and tracks changes makes your process more secure. You can also use GitOps to track authorship and secure the desired state of each cluster.

Step 2: Declare Your Infrastructure as Code

Next, you need to put your entire infrastructure as code. This ultimately helps you establish readability and simplifies maintenance. 

Any practices in your code lifecycle can also be replicated with infrastructure code. 

Using a Git repository for IaC is the most common practice to accomplish this step using GitOps. This allows you to manage collaboration, audits, and version controls. 

While you’re not limited strictly to IaC for the entire GitOps adoption, it helps to start with this step. Then anything else that you can define as code can be added to your GitOps model. So you can look to declare things like policy, compliance, security, and other operations outside of infrastructure as code during this step.

Step 3: Choose Between Push-Based or Pull-Based Deployments

There are essentially two ways to implement a GitOps—push deployments and pull deployments.

Push deployments are typically implemented with CI/CD tools. CircleCI, Jenkins, and Travis CI are popular examples. Each time an application code gets updated, the pipeline is triggered and the repository is automatically updated with the descriptors for that deployment. 

Any change to the environment repository will trigger that push pipeline. But the deployment pipeline automatically gets triggered when repository changes are made to the environment. 

Pull-based deployments continuously track the actual state of the infrastructure deployment with the desired state of the environment defined in the repository. If differences are discovered, the engineer can update the infrastructure to match the repository. 

For both of these deployment methods, you need to have some type of moderating or review process. 

Step 4: Establish Your Review Process

Most organizations and engineers will have multiple features being implemented to application code at the same time. That’s why it’s so important to use a version control system for software development and team collaboration. 

But you also need to establish a review process.

Proper Git flows use forking or new feature branches that extend from the main branch. So when a developer changes the code, pull requests can be reviewed by another team member who hasn’t worked on that code. Only after it’s been reviewed and validated by someone else can it be merged with the main branch and pushed to production or testing. 

Not only does this help you track who made changes to the code, but it also ensures that the environment is using the same version. This same process can be replicated with your infrastructure model as you’re setting up GitOps.

Step 5: Separate CI and CD

With DevOps, CI and CD are treated as a single entity and delivered to a single pipeline. But with GitOps, CI and CD are viewed as two separate processes.

GitOps views continuous integration as a development process and continuous development as an operational practice. But the GitOps workflow will ultimately merge these two entities together. 

The Git repository becomes a mediator between CI and CD. Git repos will contain all code details about the environment, and deployment processes are triggered with each commit. 

This approach ensures that the underlying infrastructure remains unchanged—the CI process never touches it.