GitOps vs. DevOps: How GitOps Makes DevOps Better

What Is DevOps?

DevOps unifies disparate development (Dev) with operations (Ops) teams into a collaborative work culture. 

DevOps is a cultural change that requires building trust between development and operations teams. The goal is to eliminate or reduce silos through collaborative work.

It involves aligning technology to business requirements and adopting technologies and practices that facilitate better communication and collaboration. 

Common DevOps practices include automation, iterative software development, and automated infrastructure deployment.

What Is GitOps?

GitOps enables development and operations teams to use Git—an open source version control and distributed code management system—for declarative configuration driving application delivery and cluster management.

Git tracks all of the changes to the application and environment configuration via commits and pull requests which triggers a synchronize event. A GitOps workflow enables teams to manage software deployment and infrastructure provisioning in an automated and reliable manner.

Technically, GitOps requires a Git repository, an environment supporting declarative configuration (like Kubernetes), and a GitOps agent that synchronizes between the Git repository, which is the source of truth, and the current state of the cluster.

How Does GitOps Address DevOps Challenges?

GitOps enhances DevOps by incorporating Git throughout the software delivery process, making it easier to orchestrate projects and keep them in sync. The end goal is to achieve smoother, faster, and more reliable software development and delivery.

GitOps pipelines use Kubernetes concepts, so they are easy to adopt by teams who already work with Kubernetes. They build on traditional DevOps practices, so changes to existing workflows are minimal for teams that have invested time in automating their software delivery.

The Kubernetes DevOps Pipeline without GitOps

A standard Kubernetes DevOps pipeline involves the following steps:

Step 1: Code commit – a developer commits code in the repository (i.e., GitHub, AWS CodeCommit). The code contains a Dockerfile, specifying the container image, and a manifest file specifying a deployment object or a Helm chart. 

Step 2: Build – a CI/CD tool processes the Dockerfile to create a new version of the container image.

Step 3: Generate artifacts – the CI/CD tool pushes the container image to an image repository.

Step 4: Deploy – The tool deploys manifest files to the Kubernetes cluster (i.e., an Amazon EKS cluster).

The first three steps are part of the continuous integration (CI), while the fourth step is continuous delivery or deployment (CD).

What Challenges Does this Process Create?

This pipeline is effective if there are no issues, but addressing problems can be tricky. Anyone with access to a cluster can run kubectl commands to modify or delete pods, intentionally or accidentally. There may also be unintended environmental consequences from other running processes, incidents, or deployments. Traditional DevOps pipelines don’t allow developers to return a cluster to its previous stable state easily. 

Once they’ve detected an issue, developers can run the CD step again. However, some changes, such as deleted pods or a modified number of replicas, may disrupt running applications. In some cases, it might be difficult to spot these issues. In other cases, the issues will be visible but fixing them can be complex and time consuming. Even after applying a fix, it can be very difficult to understand if the current state of the environment matches the desired state.

How GitOps Helps

GitOps helps address this issue by handling the CD step. The automated CI steps are often the same, but a GitOps tool like Argo runs in the cluster and keeps track of the manifest files in the code repository, ensuring the cluster remains in sync. 

With GitOps, a tool regularly synchronizes the running clusters with the desired target state in the code repository (usually GitHub). GitOps enhances the security of a cluster by separating permissions for CI and CD tasks. It works with Helm charts and standard manifest files in Kubernetes such as Horizontal Pod Autoscaling (HPA), Deployments, and StatefulSets. 

In a GitOps pipeline, a tool like Argo regularly compares the cluster state in Kubernetes to the desired state in the manifest files. If someone edits the cluster or deploys pods outside the CI/CD process, the tool detects the changes and can automatically restore the cluster to the target state. Git is the single source or truth, ensuring applications are always in sync.

Related content: Read our guide to GitOps with Kubernetes

A GitOps Adoption Guide for DevOps Teams

Organizations typically go through one or more of these four stages when adopting a GitOps model:

Stage 1: The organization moves to containerized, cloud native infrastructure and stores all deployment configurations in a Git repository. At this stage of GitOps maturity, the organization has not implemented continuous state reconciliation. This setup allows teams to provision infrastructure faster and establish repeatable, immutable workflows.

Stage 2:  The organization’s teams deploy applications based on a GitOps model, with configuration drift detection and reconciliation to keep all running applications in sync with their target state. A GitOps tool continuously checks the manifest files in Git and automatically syncs the live application. Secure GitOps pipelines allow teams to standardize and automate delivery and deployment, enabling faster, more frequent deployments while maintaining audit trails. At this stage, the organization benefits from reduced operational costs and a shorter mean time to recovery (MTTR).

Stage 3: The organization introduces additional GitOps concepts such as process standardization, security, control, and automation, across the environment. It implements GitOps cluster creation and management. These capabilities benefit the overall application infrastructure and enable development teams to operate independently. The goal of the DevOps team at this stage is to have a powerful, automated process in place with reasonable guard rails that makes developer teams self-sufficient, allowing them to focus on improvements in other areas.

Stage 4: The organization can now manage cluster fleets with the GitOps toolset, providing consistency and velocity and enforcing policies at scale. At this stage, the organization can scale software delivery consistently across multiple clouds and infrastructure options, with central, company-wide policies for deployment, enhanced visibility and granular control over thousands of clusters. 

Different organizations may benefit from different paths—an organization might want to reach a high maturity level quickly, choose to progress slowly or decide its current maturity level is sufficient. Organizations can start seeing significant benefits from GitOps by Stage 2. 

Development teams can easily reach Stage 2, implementing application GitOps practices with the right GitOps tooling. These tools allow DevOps teams to configure applications quickly and implement continuous deployment and reconciliation in Kubernetes clusters from the Git repository. This already provides significant benefits in terms of efficiency, reliability, and auditability of development processes.

At Stage 3, platform teams can use open source management tools and a cluster API to create and modify clusters across multiple regions, zones, and cloud environments. Cloud providers like Google, AWS, and Azure support a cluster API. DevOps teams can benefit from all the functionality of Stage 2, reconciling cluster config in the same way. 

Some enterprises progress to Stage 4, using a unified configuration to define multiple clusters and manage cluster fleets. Establishing a robust GitOps process with the right tooling will provide  the organization a central control plane for software delivery, agnostic to infrastructure, delivery platform, technology stack, or business unit.

Argo CD for GitOps

Argo CD is a user-friendly GitOps tool that provides a reliable diff engine and a secure architecture that works on-premises, in the cloud, and at the edge. It is a Kubernetes controller that monitors the state of resources continuously and compares them against desired states defined in Git. Once the desired state changes, the controller attempts to realize the desired configuration.

Argo CD automates the process of detecting changes to resources and reapplying the desired state when drift detection is enabled. Argo CD works with Argo Rollouts, a progressive delivery tool that can handle blue/green and canary deployments out of the box, and Argo Workflows, a workflow engine that orchestrates parallel jobs in Kubernetes.

The next step is adopting a tool like Codefresh which is powered by Argo and is built for enterprises. It provides all of the benefits of the Argo toolchain while giving teams the additional resiliency, security, support, and scalability needed for an enterprise solution.

Adopting GitOps with Codefresh

Improving your DevOps solution can seem like an insurmountable task. Teams that focus on learning and adopting GitOps can quickly translate theory into actionable process improvements. The best way to get started on that journey is with our new certification program that helps you learn the fundamentals and best practices of GitOps.

Learn more about the certification program or enroll today!

If you are ready to take the next steps in your GitOps journey, start a trial of Codefresh. Codefresh is an enterprise GitOps solution powered by Argo that can help your team accelerate their frequency of software delivery with advanced deployments like canary, blue-green, and experimental releases.

The World’s Most Modern CI/CD Platform

A next generation CI/CD platform designed for cloud-native applications, offering dynamic builds, progressive delivery, and much more.

Check It Out

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 2

No votes so far! Be the first to rate this post.