Skip to main content

Introduction

What is GitOps? Explained With Real World Examples

In this guide, discover what GitOps is and how it enhances DevOps practices.

Learn the basics, benefits, and real-world examples of GitOps to understand its impact on modern software delivery and operations.

What is GitOps?

GitOps is a technical practice that follows the DevOps philosophy.

The core idea behind GitOps is to use Git as a single source of truth for declarative infrastructure and applications.

You define the desired infrastructure configs in git, and a tool or an operator software that sits in your infrastructure watches for any changes in git. If it detects any change in git, it applies those changes to the infrastructure and brings it to the desired state. This process, known as reconciliation, is a key component of GitOps

Also, the operator software continuously monitors the state of the infrastructure. If the infrastructure deviates from the desired state (let’s say due to a manual change), the operator software ensures the infrastructure comes back to the desired state.

For example, in git, the infra config says, for autoscaling, the minimum instance count is 3, and the max is 9. The operator software deploys the autoscaling group with the values in Git.

Assume someone does a manual change, now the autoscaling min and max count is 4 and 12 now. Since the operator software continuously monitors the infrastructure, it identifies the configuration drift as compared to the git config.

So it rollbacks the manual changes to match the desired state in git.

At a high level, GitOps aims to bring the following.

  1. Git as the source of truth
  2. Developer-centric infra workflows
  3. Good traceability of infra changes
  4. Consistency and Standardization
  5. Security.
  6. No manual changes.

With Gitops workflow, infrastructure engineers/developers can focus more on engineering and innovation than on infrastructure management and maintenance.

GitOps & Kubernetes

Now, when it comes to Gitops, you mostly hear implementations around Kubernetes using Kubernetes operators.

While GitOps is commonly associated with Kubernetes, it is important to recognize that the principles and benefits of GitOps extend beyond Kubernetes.

The GitOps workflow can be applied to various infrastructure provisioning and configuration management tools, such as Terraform, Ansible, or CloudFormation.

Now lets dive deep in to GitOps Workflow and more.

GitOps Workflow

Here are the high level steps involved in GitOps workflow.

  1. Define the desired infrastructure configurations in Git.
  2. The GitOps tool sits in your infrastructure and watches for any changes in the Git repository through polling or webhooks
    1. With the polling approach, the GitOps tool periodically checks the Git repository for any changes.
    2. Webhooks provide a more real-time and efficient way of detecting changes in the Git repository.
  3. If changes are detected in Git, the GitOps tool (ArgoCD, Flux CD etc) applies those changes to the infrastructure and brings it to the desired state.
  4. The GitOps tool continuously monitors the state of the infrastructure.
  5. If the infrastructure deviates from the desired state (e.g., due to a manual change), the GitOps tool detects the configuration drift.
  6. The GitOps tool reconciles and rollbacks any manual changes to match the desired state defined in Git.
  7. If no configuration drift is detected, the GitOps tool continues monitoring the infrastructure state.

Here is an example:

  • Lets say, in Git, the infrastructure configuration specifies the autoscaling minimum instance count as 3 and the maximum as 9.
  • The GitOps tool deploys the autoscaling group with the values defined in Git.
  • If someone manually changes the autoscaling min and max count to 4 and 12, the GitOps tool identifies the configuration drift compared to the Git configuration.
  • The GitOps tool then rollbacks the manual changes to match the desired state in Git.

This workflow ensures that the infrastructure always reflects the desired state defined in Git, even if manual changes are made.

💡
While GitOps is commonly associated with Kubernetes deployments using Kubernetes operators, it is important to note that the GitOps workflow can be implemented using any tool that supports the underlying principles.

Key Principles of GitOps

At its core, GitOps aims to implement some key principles to infrastructure management:

To understand each principle with an example, lets consider a real world scenario:

CrunchOps is a technology company that is responsible for deploying new microservices based application for their client. The company wants to ensure that the deployment of the microservice goes smoothly and follows best practices for security and reliability.

The company has a dedicated DevOps team and this team is responsible for managing the company's infrastructure, which is built on Kubernetes. Also, the DevOps team plans to use ArgoCD (GitOps continuous delivery tool) for all the deployments.

With this example, lets understand the key principles of GitOps.

1. Git as the Single Source of Truth

In GitOps, the entire infrastructures desired state is defined and versioned in a Git repository.

This means that Git serves as the single source of truth for both application code and infrastructure configurations.

All configurations and code related to the microservices, including Kubernetes manifests and Helm charts, are stored in a Git repository. You can call this a deployment repository or a infrastructure repository.

This repository serves as the single source of truth for the entire deployment process.

Here's an example of an infrastructure repository structure showing Helm charts organized for different environments in Git. These charts would be deployed by ArgoCD based on the environemnts.

.
├── helm-charts
│   ├── app1
│   │   ├── Chart.yaml
│   │   ├── templates
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   └── ...
│   │   └── values.yaml
│   ├── app2
│   │   ├── Chart.yaml
│   │   ├── templates
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   └── ...
│   │   └── values.yaml
│   └── ...
├── environments
│   ├── dev
│   │   ├── app1-values.yaml
│   │   ├── app2-values.yaml
│   │   └── ...
│   ├── staging
│   │   ├── app1-values.yaml
│   │   ├── app2-values.yaml
│   │   └── ...
│   └── prod
│       ├── app1-values.yaml
│       ├── app2-values.yaml
│       └── ...
└── scripts
    ├── deploy.sh
    └── ...
💡
Note: The infra repository organization may vary based on project requirements. This is just an example.

Initial commit adds the Helm charts for the new microservices.

Subsequent commits track updates and changes, ensuring version control.

2. Developer-Centric Infrastructure Workflows

GitOps aims to manage infrastructure using familiar Git workflows.

Infrastructure changes are made through pull requests, code reviews, and merges, enabling collaboration and consistency.

In our example scenario, any changes to deployed microservies requires a pull request from a Developer/DevOps engineer.

  1. The engineer makes the necessary changes to the app1-values.yaml file in the infrastructure repository, ensuring all required configurations are included.
  2. A pull request (PR) is then created to merge these changes into the main branch. This PR includes detailed descriptions of the changes, reasons, and any relevant context.
  3. The PR gores through series of testing before it gets merged to the target branch. (Infra config validation, compliance checks, lint testing etc). These tests despends upon the respective organizations security policies.
  4. The PR is assigned to designated reviewers from the DevOps team. These reviewers thoroughly inspect the changes for correctness, potential issues, and adherence to best practices.
  5. Reviewers provide feedback, request changes if necessary, and approve the PR once all concerns are addressed.

Before the PR can be merged, it undergoes a series of automated tests.

  • Infrastructure Configuration Validation: Ensures that the changes do not break existing configurations and adhere to the required schema.
  • Compliance Checks: Verifies that the configurations meet the organization's security and compliance policies.
  • Lint Testing: Checks for coding standards and best practices.
  • Integration Tests: Runs tests to ensure that the new microservice interacts correctly with other services.

These tests are automated using CI/CD tools integrated with the Git repository (e.g., GitHub Actions, Jenkins, or GitLab CI).

Once the PR passes all reviews and automated tests, it is merged into the main branch. This action triggers ArgoCD, which detects the changes and begins the deployment process.

3. Traceability and Auditability

With GitOps, all changes to the infrastructure are tracked and versioned in Git. This provides a clear audit trail, making it easy to understand what changes were made, by whom, and when.

For example,

Each commit message includes detailed information: Add initial configuration for app-1 The Git history allows tracking changes over time.

Pull request discussions and approvals are also logged, providing context and justification for changes.

4. Consistency and Standardization

GitOps promotes the use of declarative configurations and templates, ensuring consistency across environments. Infrastructure is treated as code, enabling reproducibility and reducing the risk of configuration drift.

For example,

The Helm chart for app1 includes templates and parameterized values files. Developers only need to modify values.yaml for different environments.

5. Enhanced Security

GitOps leverages Git's built-in security features, such as access controls and code reviews. Infrastructure changes go through the same rigorous review process as application code, reducing the risk of unauthorized or unintended modifications.

For example,

Automated security tools (ex, Trivy) scan the Helm configurations for vulnerabilities. Code reviews ensure compliance with security policies.

6. Elimination of Manual Changes

GitOps discourages manual changes to the infrastructure. All changes are made through Git, and the GitOps tool automatically synchronizes the actual state of the infrastructure with the desired state defined in the repository.

In our example,

ArgoCD continuously monitors the Git repository. Any change in the repository is automatically applied to the Kubernetes cluster. If a manual change is made to the cluster, ArgoCD detects the drift and reconciles it by applying the desired state from the Git repository.

The DevOps team is notified of the drift and the corrective action taken, ensuring transparency and accountability.

Common GitOps Misconceptions

GitOps is revolutionizing how we deploy and manage infrastructure, but there are several persistent myths that need clearing up. Let's tackle the most common ones I encounter when talking to teams:

  1. GitOps is just Infrastructure as Code with extra steps" No - while GitOps uses IaC, it's a complete operational model. Think of IaC as the recipe, while GitOps is the entire restaurant kitchen system - including the workflow, quality checks, and service delivery.
  2. "It only works for Kubernetes" While Kubernetes made GitOps famous, the principles work everywhere. I've seen teams successfully apply GitOps to traditional infrastructure, databases, and even network configurations.
  3. "You need to automate everything" Start small! You don't need 100% automation from day one. Many successful GitOps implementations begin with partial automation and gradually expand. Keep those manual approval gates where they make sense.
  4. "It replaces CI/CD pipelines" GitOps complements your CI/CD rather than replacing it. Think of CI/CD as your assembly line, while GitOps is your inventory and quality control system - they work together.
  5. "Git is too complex for ops teams" Modern Git tools have made this much easier. Plus, most team members only need to know basic operations and can use GUI interfaces. The learning curve isn't as steep as you might think.

The key is starting small, focusing on value, and growing your GitOps practice gradually. Don't feel pressured to transform everything overnight.

Conclusion

In this guide, we explored the foundations of GitOps and its transformative impact on infrastructure management.

By using Git as the single source of truth, GitOps brings reliability, consistency, and traceability to DevOps workflows.

Whether you're starting small or planning a large-scale adoption, GitOps offers a powerful framework to support modern software delivery. Embrace GitOps to drive a consistent, secure, and agile DevOps culture that aligns with today’s fast-paced development demands.

Now we would like to know your thoughts on GitOps.

Are you planning to move to GitOps workflows?

Comment below!