GitOps, CI/CD, Kubernetes and Infrastructure as Code (IaC) must be terms you have come across in the ever-evolving field of modern DevOps. However, if the term GitOps is new to you, you need to know more about it. The following article takes you through all the details of GitOps, from answering the question "what is GitOps" right down to how it compares to other operational models. What is GitOps and why is it one of the hottest topics of discussion in cloud-native operations today?
By the end of this guide, you will know everything there is to know about GitOps.
What is GitOps? A Simple Definition
So, what is GitOps then, in layman’s terms? GitOps is an approach to operating systems where Git is the one and only source of truth regarding application code and infrastructure configuration. Rather than making manual changes to the server/cluster, each change – be it a new functionality, configuration change, or infrastructure change – happens via a Git commit and is automatically applied to the production environment to match the Git-declared state.
Therefore, when the question about GitOps is asked, the quick answer would be – it’s a way of managing your infrastructure and deployments where Git is not a mere code repository, but your whole system’s control point.
The term itself has been coined back in 2017 by Weaveworks.
What is GitOps Built On? The Core Principles
In order to get a better understanding of GitOps, it is crucial to examine the fundamental concepts upon which it is based. The majority of definitions of GitOps can be summed up as four main principles:
1. Declarative Configuration
Everything — infrastructure, applications, and configurations of the system are described declaratively. In other words, instead of scripting how to achieve certain state, one describes the desired state, using such languages as YAML or JSON.
2. Versioned and Immutable Storage (Git)
Declarative configuration is stored in Git and hence, it contains the complete and immutable history of all changes that have ever been made to it. It is the key concept of GitOps, since it means that Git not only stores your application code, but serves as the immutable history of the desired state of the whole system.
3. Automated Delivery
Committing changes to Git causes the operator or the agent (Argo CD, Flux, etc.) to apply these changes to the target environment.
4. Consistent Reconciliation
The GitOps agent continually monitors the live environment and compares it against the state declared in Git. In case of drift, i.e., the live environment does not align with the Git-declared state, the GitOps agent corrects the drift by alerting the team or by auto-synching the environment back to the required state.
These four principles provide an answer to the deeper question "what is GitOps?" It is not just a tool or a practice but an entire operational paradigm centered on GitOps automation and consistency.
What is GitOps Compared to Traditional DevOps?
One of the confusions that people have is in regards to the definition of GitOps relative to regular DevOps or even CI/CD. Although GitOps follows the practices of DevOps, there is a difference in the way the deployment is done.
In traditional CI/CD, changes are pushed into production using pipelines whereas in GitOps, changes are made using Git commits for reconciliation. Traditional CI/CD has scattered configurations, partial change tracking, manual rollbacks and limited drift detection whereas GitOps uses Git as the source of truth for its complete commit history, rollbacks using git revert and continuous drift detection. Traditional CI/CD involves pushing changes whereas GitOps is pull-based which involves fetching the desired state by the agent running in the cluster.
Why Does GitOps Matter? Key Benefits
With a basic understanding of what GitOps provided, now we should focus on the reasons for its popularity among different organizations.
1. Better Auditibility
As all changes are made via Git, then automatic audit trail is ensured automatically. It shows the person who performed the action, what was changed, and why (because of commit messages and pull requests). That is why compliance-related industries are especially attracted to the concept of what is GitOps.
2. Easier and Safer Rollback Process
As the desired state can be found in the Git version history, then to rollback the incorrect deployment, it is necessary to revert the commit only. The GitOps agent will notice the change and reconcile the environment to the previous one.
3. Less Config Drift
As there is continuous reconciliation, the configuration drift will happen rarely. In case somebody makes manual changes in the cluster, it will be detected and corrected by the GitOps agent.
4. Improved Collaboration
With the changes being propagated via pull requests, GitOps automatically integrates the code review into infrastructure and deployment changes, providing the same level of collaboration advantages already enjoyed with application code.
5. Higher Security Level
Since the GitOps agent retrieves the changes from Git without requiring any other system to be able to push to the cluster, the attack vector is minimized as fewer systems are required to have direct access to your production environment.
6. Environment Consistency
The declarative configuration kept in Git simplifies environment consistency replication significantly, reducing "works on my machine" type of issues.
What is GitOps in Practice? How the Workflow Looks
Reading about what GitOps is from the books is one thing; experiencing GitOps is another thing entirely. Here is how a typical GitOps flow looks like:
- A developer or an engineer makes a modification to the system. The modification could be either an application code modification or infrastructure modifications (for example, modifying the Kubernetes manifest).
- The modification is committed to a Git repository and usually happens through a pull request which will be reviewed by other developers as well.
- The pull request will be reviewed, and then the modification will be merged to the master branch (just as in regular code review).
- The GitOps tooling (Argo CD/Flux) detects the change in the Git repository.
- GitOps tooling automatically performs a synchronization between the live environment and what is described in the Git repository.
- The GitOps tooling continuously compares the live environment and what is described in the Git repository, and automatically reconciles any discrepancy that it detects.
Popular Tools Used in GitOps
A number of different tools have emerged that are key enablers for implementing what is GitOps:
Argo CD - one of the most popular GitOps continuous delivery tools for Kubernetes, featuring graphical UI and automatic synchronization capabilities
Flux - lightweight CNCF graduate GitOps tool that constantly reconciles state of a cluster against Git
Jenkins X - combining CI/CD pipelines with GitOps approach, but in the context of Kubernetes-native applications
Terraform (used with GitOps approaches) - though not GitOps-native tool per se, Terraform is commonly used in combination with GitOps approaches for infrastructure management
Crossplane - an implementation of GitOps for infrastructure provisioning in the cloud
Which of them you choose will depend on your current stack, but Argo CD and Flux will still be the most common places to start from when considering what is GitOps for you.
What is GitOps Used For? Common Use Cases
GitOps is not restricted to just one type of workload. Some typical use cases of what is GitOps as an approach are as follows:
Management of Kubernetes clusters - the most popular use case, where the manifests, Helm charts, or Kustomize are managed using Git and are auto-synced
Multi-cluster and multi-environment management – leveraging Git branches or repositories in order to maintain consistency across dev, staging, and production environments
Provisioning of infrastructure – GitOps applied to cloud infrastructure elements such as networking, storage, and computing with the help of Crossplane or Terraform
Disaster recovery – since everything is stored in Git, rebuilding the entire environment becomes easy and reliable
Progressive delivery – GitOps combined with canary/blue-green deployments for safe rollouts
Challenges and Limitations of GitOps
Despite all these compelling arguments for using GitOps as an operation paradigm, there are some drawbacks associated with it:
Learning curve — teams who are not accustomed to declarative infrastructure and native Kubernetes tools will require some time to get used to that approach
Secrets management — keeping credentials inside of Git will require additional software (e.g., Sealed Secrets or secret management software outside of Git repositories) because Git itself is not designed for storing credentials
Tooling overhead — configuration of GitOps operators, repository management and synchronization policies will require additional efforts
Not suitable for all workloads — not every application can be represented by declarative infrastructure; sometimes some amount of additional engineering is required to fit them into GitOps paradigm
Getting acquainted with these limitations is as important as understanding GitOps itself.
GitOps vs Traditional Infrastructure Automation
It would be wise to define what is GitOps within the context of wider practices of infrastructure automation, which are often mistakenly referred to interchangeably.
Infrastructure automation as an approach utilizes tools such as Ansible or scripts written using Terraform, for instance, with an emphasis on the way how those changes are implemented — imperative scripts are written by hand or run in a CI environment. GitOps, however, places the accent on the target state and an automated agent which tries to achieve convergence between the real-world system and this state constantly.
Getting Started: How to Begin Implementing GitOps
Now that you are fully persuaded with what is GitOps and how to implement it, here is an action plan to get started:
- Instead of attempting to implement GitOps in all of your infrastructure, begin by implementing it on one Kubernetes cluster.
- Move the manifests to a Git repository and ensure their organization according to the environment in which they will run (dev, staging, and production).
- Deploy a GitOps operator like Argo CD or Flux, and hook it up with your repository.
- Implement secrets management prior to including any configuration files.
- Implement pull request workflows for the infrastructure, as you would for applications.
What is GitOps Architecture? Understanding the Moving Parts
In order to understand more about what is GitOps technically speaking, one should get an overview of the architecture which enables the whole operation to happen. The typical GitOps stack includes the following components:
The Git Repository (Source of Truth)
This is the place where all the configuration declaratively exists – Kubernetes manifest files, Helm values files, Kustomize overlays, Terraform config. Generally, when working with GitOps stacks, teams keep the separation between application code repositories and configuration/environment repositories to be able to review and merge infrastructure-related changes separately from application code-related changes.
The GitOps Operator/Agent
This is the software component which runs inside the cluster (or outside it in case you want to deploy infrastructure with the use of GitOps) which constantly monitors the Git repo for any changes. Once the new commit appears, it retrieves the latest configuration and deploys it. The two major players on the market here are Argo CD and Flux.
Reconciliation Loop
Probably, the most significant feature of GitOps architecture is this one. The operator does not only make adjustments, but rather implements an infinite loop, which periodically compares the actual state of the system with the desired one that is described by Git. Depending on the configuration of the synchronization policy, it can either fix the problem or notify about it automatically.
Notification and Alerting Layer
In most production GitOps implementations, the layer of notification is included, usually via Slack, email or any other way. It helps to know if synchronization was successful or failed and if there was drift detected and fixed. That is how you get GitOps implementation to be operationally trusted.
Knowing these four parts of the architecture, you get a clearer idea of what GitOps is in practice.
What is GitOps' Role in Multi-Cluster and Multi-Environment Setups?
As companies grow in size, they will not be working with one cluster or one environment only. It is therefore vital to understand what GitOps is when considering multiple clusters.
There are two repository structuring styles that are commonly used:
Mono-repository style – All environments, including dev, staging, and production, are kept in one single repository and divided into directories or branches. This allows everything to be stored in one place and is easy to work with. However, this may become complicated depending on how many environments there are.
Poly-repository style – Each environment or cluster is given its own repository. While this approach allows for more organization, it also requires more work when applying changes across all environments.
GitOps operators like Argo CD provide the ability to use ApplicationSets and other tools for creating the same application multiple times in different environments by using only one template – a method that has become increasingly popular with scaling up what is GitOps beyond a single cluster POC.
What is GitOps' Impact on Team Culture and Workflow?
Besides the technology itself, it may be valuable to discuss what is GitOps impact on team culture and practices.
Infrastructure Changes Require Code Review
The first cultural practice to consider is that changes to the infrastructure now have to be reviewed via pull request just like the changes to application code do. This results in having more people looking at any change before production use, as well as a documentation of the reasoning behind each change (via PR comments).
More Developer Autonomy but Also Safety
Due to the fact that GitOps uses declarative infrastructure configuration and automated reconciliation, developers can now propose infrastructure changes via pull requests without requiring standing credentials. The idea of "self-service with guardrails" is probably the most underestimated cultural aspect of GitOps practices.
Operations Become Proactive Rather Than Reactive
Because of continuous reconciliation of the drift state, operations team does not have to constantly fight fires and fix issues caused by manual changes and can spend more time on improving the overall architecture of the system — which is one of the main reasons companies are interested in what is GitOps.
Measuring Success: How Do You Know GitOps Is Working?
Once a team has implemented GitOps, there are some key metrics that should be tracked in order to assess the value of this implementation:
Frequency of deployments – most teams have observed an increase in the number of safe deployments due to automation and predictability in the process
Time to recovery (MTTR) – as rolling back to a previous deployment version is no harder than doing a git revert, recovery becomes significantly faster
Drift incidents – tracking the number of drift incidents will provide information about discipline in making changes through Git
Deployment failure rate – because of mandatory code reviews for infrastructure changes, the number of failures and rollbacks is decreased
These are the exact metrics in the context of DORA (DevOps Research and Assessment) framework, and they are very relevant when assessing the actual impact of GitOps on delivery performance of a team.
A Simple Real-World Example
To make what is GitOps more concrete, consider a small example. Suppose a team wants to scale a Kubernetes deployment from 3 replicas to 5.
In a traditional, manual approach, an engineer might run kubectl scale deployment my-app --replicas=5 directly against the cluster — a change with no review, no audit trail beyond cluster logs, and no easy way to revert if something goes wrong.
In a GitOps approach, the engineer instead edits the replicas: 3 field in the deployment's YAML manifest to replicas: 5, commits the change, and opens a pull request. A teammate reviews and approves it. Once merged, the GitOps operator detects the change in Git, applies it to the cluster, and the deployment scales up automatically. If it later needs to be reverted, a single Git revert brings it back to 3 replicas — with the entire history preserved.
This small example captures the essence of what is GitOps in daily practice: every change, however small, flows through Git first.
Frequently Asked Questions About GitOps
What is GitOps?
In simple terms, it is a technique that uses Git as the single source of truth and automated tools to keep the actual state of the system in sync with the desired Git-defined state.
What does GitOps serve its purpose for?
GitOps is used mainly to manage the state of Kubernetes clusters, with manifests defined in Git and automated tools applying them continuously to maintain synchronization, such as Argo CD and Flux.
How is GitOps related to DevOps?
GitOps can be seen as an implementation of DevOps philosophy with the particular operational pattern of Git as a control plane and pull-based, agent-driven reconciliation.
How is GitOps different from CI/CD?
CI/CD aims to automate the process of building, testing, and deploying the code. GitOps uses Git as a source of truth and leverages an in-cluster agent to pull and reconcile the changes.
Is Kubernetes required for GitOps?
Although GitOps emerged mainly due to Kubernetes technologies, the philosophy of using declarative configuration and version control and reconciling changes automatically applies to other systems as well.
Which is the best tool for beginners to learn about GitOps?
There are a number of GitOps tools available on the market. However, Argo CD seems to be the best for beginners learning about GitOps due to its visual interface and community support.
Conclusion
So what is GitOps at the end of the day? GitOps is an innovative operational model that leverages Git as the source of truth when it comes to your infrastructure and application deployment, making push-based manual processes obsolete by replacing them with pull-based automation. By embracing what is GitOps in a professional capacity, you can achieve greater audibility, better rollback options, reduced drift, and a more collaborative way of handling your infrastructure. If you want to have a more comprehensive learning experience and expand your knowledge base regarding cloud-native operations and technologies in general, not just what is GitOps, then perhaps you should check out a Data Science Course.
