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:
    kubectl apply -f k8s/deployment.yaml

​
Challenges in DevOps Deployment

ChallengeImpact
Cluster credentials in CISecurity risk if credentials are leaked or compromised.
CI tool couplingMigrating to another CI/CD system requires rewriting deployment logic.
Limited auditabilityHarder to track “who changed what” outside Git history.
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

OptionProcess
A1. Install a GitOps agent (e.g., Argo CD, Flux) in the cluster.
  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:
kubectl set image deployment/app app=repo/app:v1.2.3
git commit -am "chore: bump image to v1.2.3"
git push origin main
  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

FeatureDevOpsGitOps
Source of TruthCI/CD tool + GitGit repository only
Cluster Credential ScopeStored in CI serverOnly the in-cluster agent has access
Audit & RollbackCustom scripts & logsGit history and simple git revert
Tool CouplingCI/CD-specificAny Git-compatible workflow
Security & ComplianceBroader attack surfaceReduced credentials exposure, easier policy enforcement

Watch Video