Getting Started with GitOps: A Practical Guide to Continuous Deployment

In the fast-paced world of DevOps, deployment bottlenecks and human error can slow you down—and even topple production environments. Manual scripts, ad-hoc commands, and undocumented one-off fixes lead to inconsistent environments, configuration drift, and lengthy release cycles. Enter GitOps: a framework that uses Git as the single source of truth for both application code and infrastructure configuration, and relies on automated GitOps tools to reconcile your live environments with what’s stored in version control.

By treating your deployment manifests as code in Git, teams eliminate manual steps, enforce peer reviews on every change, and achieve continuous deployment with clear audit trails. In this guide, we’ll explain the fundamentals of GitOps, show you why it stops manual errors and drifts dead in their tracks, and walk through a practical example of deploying a simple web app to Kubernetes using Argo CD, currently my favorite GitOps tool.

What is GitOps?

GitOps is a framework for managing infrastructure and application deployments using Git version control as the central source of truth. In a GitOps workflow, all the configuration that defines your systems – for example, Kubernetes manifests describing deployments and services – is stored as code in a Git repository. Any change to your infrastructure or application desired state is made by modifying these files in Git (often via a pull request), rather than by manual changes to live systems. Once changes are committed and approved, they serve as the authoritative desired state.

By relying on Git, GitOps provides a declarative approach to infrastructure. You declare what the system should look like (using configuration files), not how to make those changes manually. A separate process or tool then ensures the actual environment matches this declared state. This means every change is version-controlled and auditable – you have a history of who changed what and when, making updates and rollbacks straightforward . Using Git as the single source of truth ensures consistency across environments, because you’re always applying changes from the same recorded source, not making ad-hoc adjustments on the fly.

To illustrate, suppose you want to update the number of replicas for a microservice in production. With GitOps, you would edit the replicas field in the Kubernetes deployment YAML file in the Git repo and commit that change (typically via a pull request). That commit, once merged, is the trigger for the update – an automated process will apply the new configuration to the cluster so that the actual state aligns with the Git repository. No manual runs of kubectl applyneeded on the cluster; instead, a GitOps tool takes care of applying the change. This model applies DevOps best practices like version control and code review to operations changes, aligning development and operations teams on a common process.

Benefits of GitOps for CI/CD

Adopting GitOps for continuous deployment offers several important benefits:

• Auditability and Traceability: Because all environment changes go through Git, you have an immutable history of every change. Every commit is a record of what changed, who made the change, and when. This level of auditability improves security and compliance, providing a clear trail for investigations or reviews . If an issue occurs, teams can retrace changes via commit history and understand context quickly.

  
  

• Reliability and Consistency: GitOps makes your deployments more reliable by eliminating configuration drift between environments. Since the desired state is stored in Git and automatically applied, all environments (development, staging, production) can be kept consistent. If something goes wrong, rollback is easier – you can revert to a previous Git commit, and the system will return to that known good state. This reduces the chance of manual errors and unknown hotfixes, leading to more stable environments.

  
  

• Continuous Deployment Automation: GitOps integrates tightly with CI/CD pipelines to enable automated deployments. Changes to the repository can trigger workflows that deploy the updates to your infrastructure, so releasing a new version is as simple as merging a pull request . There’s no need for manual deploy scripts or clicking around in a dashboard for routine releases. This speeds up delivery and lets teams ship updates to production faster and more frequently (true continuous deployment).

  
  

• Developer Alignment and Collaboration: Using Git as the common interface for deployments means developers and operations follow the same workflow. Developers can propose infrastructure changes through the familiar Git process (branches, pull requests, code review), and operations teams can review and manage these changes in the same way they handle code. This alignment fosters better collaboration and removes silos. Git’s built-in collaboration features (like PR reviews) ensure changes are peer-reviewed and discussed before being applied, improving quality and shared ownership.

  
  

• Transparency and Security: With GitOps, nothing is changing in your environments that isn’t in Git. This transparency makes it easy to see at any time what configuration is supposed to be in place. Unauthorized or out-of-band changes are detected by the GitOps system and can be automatically corrected. Additionally, since all changes must be committed to Git, you can enforce role-based access and approvals on those repos to control who can modify infrastructure code. This reduces the attack surface on live systems – CI/CD tools or GitOps agents apply changes, so direct access to production is minimized.

  
  

Overall, GitOps brings a standard, Git-based workflow to infrastructure and application management, which improves both developer experience and operational stability. Teams get the rapid iteration benefits of DevOps, while ensuring that every change is recorded and can be rolled back if needed.

How GitOps Works with CI/CD Automation

Now let’s see how GitOps actually works in practice, especially in the context of a CI/CD pipeline. At its core, GitOps adds a deployment automation step that continuously reconciles your running environment with what’s in Git. This is often implemented with a pull-based deployment mechanism: instead of your CI pipeline “pushing” changes out to the cluster—which would require your CI system to hold elevated cluster credentials — a GitOps tool periodically pulls updates from the repository and applies them to the cluster.

This pull model delivers key security benefits:

• Least-privilege access: You can grant the GitOps tool only the minimal rights it needs (read access to your Git repo and limited apply privileges on the cluster), rather than exposing your entire CI pipeline to production credentials.

  
  

• Reduced attack surface: Because the cluster only allows inbound pull requests from the GitOps tool, there’s no open port or credential store in your CI system that attackers could target to push unauthorized changes.

  
  

• Immutable audit trail & continuous reconciliation: Every change originates from a Git commit, giving you a clear record of who changed what and when. GitOps tools continuously compare the cluster’s actual state against the declared state in Git, and will automatically revert any ad-hoc modifications (for example, manual kubectl edits) back to the Git-defined configuration—ensuring that only approved Git history can alter the live environment.

  
  

• Separation of duties: Developers and CI focus on building and testing artifacts, while the GitOps tool handles deployments. This clear division prevents accidental or malicious deployments outside of the Git review process.

  
  

By shifting deployments to a pull-based GitOps tool, you not only streamline continuous deployment but also enforce stronger security controls around cluster access and change management.

For example, consider the workflow when using GitOps for a Kubernetes application:

Step 1: Continuous Integration (CI) builds the app

A developer merges code changes, triggering the CI pipeline (using tools like Jenkins, CircleCI, or GitHub Actions) to run tests and build a new container image. The CI process pushes this image to a container registry.

Step 2: GitOps update in Git

Once a new version is ready, the deployment configuration (for instance, a Kubernetes Deployment YAML specifying the container image tag) is updated in the Git repository. This could be done manually via a pull request or automated by the CI pipeline. Either way, the source of truth (Git) now reflects the desired state (e.g., “deploy version 2 of the app”).

Step 3: GitOps tool detects the change

The GitOps tool continuously watches the Git repository (often via webhooks or polling) and pulls the latest config when it sees a new commit.

Step 4: Sync to the cluster

The GitOps tool compares the desired state from Git with the current state of the Kubernetes cluster and applies only the changes needed to reconcile the two. Kubernetes then rolls out the update—creating new pods with the updated image—until the live state matches what’s declared in Git.

Step 4: Continuous reconciliation

The GitOps tool keeps monitoring the cluster. Once the deployment is updated, it reports the application as Synced(meaning the live state matches the Git state). If someone manually changes a resource on the cluster, the tool will notice the cluster is now “OutOfSync” with Git and can alert or automatically revert the cluster to the Git-defined state. This ensures that Git remains the single source of authority.

In a nutshell, GitOps ties your version control system to your cluster in an automated loop. Whenever Git changes, your cluster updates; if the cluster diverges, it’s corrected. This approach supports CI/CD automation by decoupling deployment from the application build process—your CI handles building and testing, and your GitOps tool handles deployments based on Git commits. The result is a robust continuous deployment pipeline where code that passes tests can move to production simply by updating a Git file, with the GitOps tool doing the rest.

Getting Started with GitOps on Kubernetes (Using Argo CD)

To start adopting GitOps, you’ll need a GitOps operator/tool and a declarative setup of your environment. In the Kubernetes ecosystem, Argo CD is one of the most popular tools to implement GitOps. Argo CD is a Kubernetes-native continuous deployment tool that runs in your cluster and keeps it in sync with your Git repository. It automates the deployment of applications by monitoring your Git repos for changes and applying those changes to Kubernetes, effectively acting as the bridge between Git and your cluster.

Setting up Argo CD in a Kubernetes cluster is straightforward. You can install Argo CD via Kubernetes manifests or Helm charts. Once installed, Argo CD itself is configured declaratively (you can define Argo CD’s config as YAML, or use its web UI). The basic steps to get started are:

Step 1: Prepare your Git repository: Ensure you have a repo (or a folder in a repo) with your Kubernetes manifests (YAML files) for the application or infrastructure you want to deploy. This might include Deployment, Service, and ConfigMap files for a simple web application.

Step 2: Install and configure Argo CD: Deploy Argo CD into your Kubernetes cluster (for example, apply the official Argo CD manifests). Then access the Argo CD web UI or CLI to define an “Application.” An Argo CD Application ties together the Git repo and the target cluster/namespace. You specify the repository URL, the path within the repo (if your manifests live in a subdirectory), the revision (branch or tag) to watch, and the destination cluster (often just your current cluster) and namespace to deploy into. You can also set the sync policy (automatic or manual). For a GitOps approach, you’ll typically enable automatic syncing, so Argo CD will apply changes from Git on its own.

Step 3: Argo CD deploys the current state: When you create the Argo CD Application, it immediately checks the Git repository for the manifests at the specified path and deploys them to the cluster. For instance, if your repo contains a Deployment for a web app, you’ll soon see that application running in Kubernetes. In the Argo CD dashboard, you can view the application’s status. Initially, it should show Synced if everything from Git is applied. If something cannot be applied (say a mistake in a YAML), Argo will report an error.

Step 4: Iterate with GitOps workflows: Now the real power comes when you make changes. Suppose you want to update the web application’s Docker image tag or scale up the replicas. You make that change in the Git repo (edit the YAML and push a commit). Argo CD will detect the change and automatically synchronize the cluster to match. Within a short time, the Kubernetes cluster reflects the new configuration – for example, new pods with the updated image will be running. Argo CD will again mark the application as synced when done. At no point did you directly intervene on the cluster; Argo CD handled the deployment based on the Git commit.

Step 5: Observe and manage through Argo CD: You can follow the deployment progress in Argo CD’s web UI. It shows a visual status of Kubernetes resources and whether they are in sync with Git. If something is out of sync or fails to deploy, Argo CD flags it. You can even configure notifications or webhooks to alert your team on sync issues or completion. Over time, you might connect Argo CD to multiple applications or even multiple clusters, but the principle remains the same: Git changes drive deployments.

This simple workflow (often called a “GitOps pipeline”) drastically reduces manual steps in releasing software. Developers only need to commit the desired state, and the GitOps tool takes care of the rest. The Kubernetes platform is particularly well-suited for GitOps because of its declarative nature – practically everything in Kubernetes (deployments, services, config maps, etc.) can be defined in YAML manifests that live in Git.

GitOps in Action: Deploying a Simple Web Application

To solidify these concepts, let’s walk through a concrete example of GitOps with Argo CD. Imagine we have a simple web application (for example, a static website or a basic Node.js app packaged into a Docker container) that we want to deploy on a Kubernetes cluster using GitOps principles.

Step 1: Version control the app configuration

First, we create a Git repository for our application’s deployment configuration. In this repo, we add Kubernetes manifest files that declare the app’s desired state. For instance, we might have a Deployment.yaml specifying the container image (e.g., myapp:v1.0), replicas, and other settings, and a Service.yaml to expose the app on a certain port. This Git repo is now the source of truth for how our app should run in the cluster.

Step 2: Set up Argo CD to watch the repo

Next, we install Argo CD on the Kubernetes cluster (if not already done). Using Argo CD’s UI or CLI, we create a new Argo CD Application pointing to our repository. We tell Argo CD which path contains the Kubernetes manifests and what environment (cluster/namespace) to deploy to. We enable automatic synchronization. At this point, Argo CD immediately pulls the manifests from the repo and deploys our web application onto the cluster. If we check Kubernetes, we’ll see our pods running and serving the app, all deployed by Argo CD. Argo CD’s dashboard will show the application status as healthy and synchronized.

Step 3: Make a change via Git to trigger a deployment

Now let’s say we have a new version of our web app (v2.0) ready to release. We build and push a new Docker image for it (this is handled by our CI process). To deploy this new version with GitOps, we update the image tag in the Deployment.yaml from v1.0 to v2.0 and commit this change to the Git repository (again, likely via a pull request that is reviewed and then merged). This Git commit is the only action needed to initiate the deployment – no separate manual deploy step.

Step 4: Argo CD detects and deploys the change

Once the new commit appears in the repo, Argo CD notices it (thanks to the webhook we set up or its polling mechanism). Argo CD fetches the updated YAML and sees that the desired state has changed (the image version is now v2.0). It then applies this change on the Kubernetes cluster: under the hood, Argo CD uses Kubernetes APIs to update the Deployment. Kubernetes spins up new pods with the v2.0 image and gradually replaces the old ones (since Kubernetes deployments do rolling updates by default). Argo CD monitors this rollout. During this process, Argo’s view will show the application as Out of Sync (because the cluster was momentarily not at the desired state), and once all the new pods are up and running, it will return to Synced status, indicating the cluster now matches the Git config.

Step 5: Verification and continuous alignment

After the deployment, we can verify that our web app is updated (perhaps by checking the app’s version or features). Argo CD provides a log of the sync operation and the outcome. Importantly, if something had gone wrong – say the new image was faulty – we could simply revert the commit in Git (or fix it with a new commit), and Argo CD would roll back the change by applying the previous configuration. Additionally, if someone tries to change the app directly in Kubernetes (for instance, using kubectl to edit the Deployment), Argo CD will detect this drift. Because the change wasn’t done via Git, Argo CD can either alert us or automatically revert the cluster to the last known Git state . This guards against config drift and ensures only Git changes are the way to modify deployments.

Through this example, you can see how GitOps with Argo CD enables continuous deployment in a safe, controlled manner. Developers focus on making changes in Git, and the delivery to Kubernetes is handled by automation. Every change is visible, reviewed, and recorded, yet deployments happen rapidly without direct human intervention in the cluster.

Next Steps and Other GitOps Tools

Getting started with GitOps is as much about tools as it is about adopting a mindset. Here are some actionable next steps if you’re ready to dive in:

• Experiment with a demo project:

  Set up a local Kubernetes cluster (using tools like Minikube or kind) and install Argo CD. Create a simple application (like the example above) and try deploying it with GitOps. Commit changes to your Git repo and watch Argo CD synchronize those changes to your cluster. This hands-on practice will solidify how GitOps works.

  
  

• Integrate CI pipelines with GitOps:

  If you have CI in place (Jenkins, GitLab CI, GitHub Actions, etc.), update your pipeline to push configuration changes to a GitOps repo instead of deploying directly. For example, have your CI pipeline open a pull request to update the Docker image tag in the manifest after a successful build. This way, CI handles building and testing, and GitOps (CD) handles the deployment upon merge.

  
  

• Implement safeguards and reviews:

  Treat your infrastructure repo with the same rigor as your application code. Use branch protections, pull request reviews, and automated checks (YAML linting, Kubernetes manifest validation) on your GitOps repo. This ensures quality and security before changes reach your cluster. You can also explore policy-as-code (e.g., Open Policy Agent) to enforce guardrails on deployed configs.

  
  

• Explore advanced GitOps patterns:

  As you grow more comfortable, manage multiple environments (dev/staging/prod) with GitOps. This might involve using separate branches or directories for each environment, or even separate repos. Tools like Kustomize or Helm can template configurations for different environments while keeping everything in Git. You can also adopt progressive delivery—canary or blue-green deployments—by integrating Argo CD with Argo Rollouts or Flagger.

  
  

Certification & Training Resources

Deepen your GitOps expertise with structured courses and certifications. For example, Codefresh Learning offers:

• GitOps Fundamentals – Core principles and workflow foundations

• GitOps at Scale – Strategies for managing large-scale, multi-cluster environments

• GitOps Enterprise – Best practices for enterprise adoption, security, and governance

  Check out their catalog at learning.codefresh.io.

  
  

Finally, it’s good to know that Argo CD isn’t the only GitOps tool. GitOps as a concept can be implemented with various platforms and services. Some other popular tools to explore include:

• Flux CD: A lightweight CNCF tool that provides continuous deployment by tracking Git repos and syncing changes to Kubernetes.

• Jenkins X: A Kubernetes-native CI/CD platform which applies GitOps principles for managing environments and releases.

• Spinnaker: A mature multi-cloud continuous delivery platform that can be configured to pull configurations from Git and support GitOps workflows across multiple clouds or clusters.

• Others: Tools like Fleet (by Rancher) for large-scale cluster management, and OpenShift GitOps (Red Hat’s Argo CD–based service for OpenShift) are also worth exploring. The GitOps ecosystem continues to grow—find the toolset that best fits your team’s needs.

  
  

GitOps brings reliability, speed, and collaboration to the software delivery process by unifying deployment automation with the version control system developers love. By getting started with Argo CD and Kubernetes—and leveraging structured training—you can experience how continuous deployment becomes safer, more efficient, and fully auditable with Git at the core. Embracing GitOps means every change is intentional, trackable, and recoverable—a practical recipe for confident, repeatable deployments. Happy shipping!