Skip to main content
GitOps is best understood as an evolution of DevOps that focuses exclusively on application delivery through Git as the single source of truth. While DevOps spans the entire CI/CD lifecycle—including build, test, deployment, monitoring, and governance—GitOps zeroes in on declarative infrastructure and automated cluster reconciliation.

​
DevOps Deployment Workflow

In a traditional DevOps pipeline, the CI server (e.g., Jenkins, GitLab CI, CircleCI) handles both build and deployment:
  1. Commit & Build
    • A developer pushes code to a Git repository.
    • The CI server runs unit tests, builds the application, and packages it into a Docker image.
  2. Push Image
    • The image is tagged (e.g., repo/app:v1.2.3) and pushed to a container registry (Docker Hub, ECR, GCR).
  3. Deploy to Kubernetes
    • The same CI pipeline uses stored Kubernetes credentials to apply manifests directly:

​
Challenges in DevOps Deployment

Storing Kubernetes credentials in your CI/CD server can expose your cluster if the server is compromised.

​
GitOps Deployment Workflow

GitOps decouples build from deploy by introducing an in-cluster agent (often called an operator) that continuously reconciles Git state with the live cluster.

​
Common CI Steps (Same as DevOps)

  1. Developer commits code.
  2. CI server builds, tests, and pushes the Docker image to the registry.

​
Deployment Options

  1. Agent watches registry tags or watches the Git repo directly.
  2. On detecting a new tag, agent updates or pulls manifests and applies changes. | | B | 1. Extend CI pipeline to clone the manifests repo.
  3. CI updates deployment.yaml with the new image tag:
  1. CI opens a Pull Request against the manifest repository.
  2. After review & merge, the in-cluster agent pulls and applies the updated manifests. |
In both options, the CI server never needs direct access to Kubernetes. All deployment actions are driven by Git operations.

​
Key Benefits of GitOps

Watch Video