DevOps GitOps

GitOps is a modern operational model where Git is the single source of truth for both application code and infrastructure configuration. Every change to the system — deploying new code, scaling resources, updating configuration — happens through a Git commit. Automated tools continuously watch the Git repository and keep the live system in sync with it.

The idea is simple: if it's not in Git, it doesn't exist. If the system doesn't match what's in Git, something automatically fixes it.

Core GitOps Principles

1. Declarative: The entire system state (infrastructure + application) is described declaratively in Git. YAML files define what the system should look like, not how to get there.
2. Versioned and Immutable: Git history provides a complete, immutable record of every change. Any state can be recreated by checking out a previous commit.
3. Pulled Automatically: Approved changes in Git are automatically applied to the target system — no manual kubectl commands or SSH sessions.
4. Continuously Reconciled: Automated agents constantly compare the desired state (Git) with the actual state (cluster). Any drift is corrected automatically.

GitOps vs Traditional CI/CD

Push vs Pull Deployment Model

Push Model (Traditional CI/CD)

The CI/CD pipeline runs kubectl apply or helm upgrade from within the pipeline — pushing changes to the cluster. The CI system needs credentials to access the cluster.

Pull Model (GitOps)

An agent running inside the cluster watches the Git repository. When a change is detected, the agent pulls it and applies it. The cluster only needs read access to Git — not the other way around. This is significantly more secure.

ArgoCD – GitOps for Kubernetes

ArgoCD is the most popular GitOps tool for Kubernetes. It runs inside the cluster, watches one or more Git repositories, and ensures the cluster matches the desired state defined in those repos.

ArgoCD Key Features

• Web UI dashboard showing the sync status of all applications.
• Automatic sync — applies Git changes without human intervention.
• Self-healing — reverts manual changes that deviate from Git.
• Rollback — click a button in the UI to restore any previous Git state.
• Multi-cluster support — manage many clusters from one ArgoCD instance.
• SSO integration and RBAC for team access control.

ArgoCD Application Definition

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: webapp
  namespace: argocd
spec:
  project: default

  source:
    repoURL: https://github.com/myorg/k8s-manifests
    targetRevision: main
    path: apps/webapp

  destination:
    server: https://kubernetes.default.svc
    namespace: production

  syncPolicy:
    automated:
      prune: true       # Delete resources removed from Git
      selfHeal: true    # Auto-fix drift from Git state
    syncOptions:
      - CreateNamespace=true

With this configuration, any change merged to the main branch of k8s-manifests inside the apps/webapp directory will be automatically applied to the production namespace within seconds.

Flux – Alternative GitOps Operator

Flux is another popular GitOps operator, also a CNCF project. It works similarly to ArgoCD but takes a more component-based, modular approach. Flux integrates natively with Helm and Kustomize.

Key Flux Components

• Source Controller: Watches Git repos, Helm charts, and OCI registries for changes.
• Kustomize Controller: Applies Kustomize configurations to the cluster.
• Helm Controller: Manages Helm releases declaratively.
• Notification Controller: Sends alerts and events to Slack, Teams, and webhooks.

GitOps Repository Structure

A clean GitOps repository separates environment-specific configuration:

k8s-manifests/
├── base/
│   └── webapp/
│       ├── deployment.yaml
│       ├── service.yaml
│       └── kustomization.yaml
├── overlays/
│   ├── dev/
│   │   ├── kustomization.yaml
│   │   └── patch-replicas.yaml    # 1 replica in dev
│   ├── staging/
│   │   ├── kustomization.yaml
│   │   └── patch-replicas.yaml    # 2 replicas in staging
│   └── production/
│       ├── kustomization.yaml
│       └── patch-replicas.yaml    # 10 replicas in production
└── argocd/
    ├── webapp-dev.yaml
    ├── webapp-staging.yaml
    └── webapp-production.yaml

Kustomize applies base configurations and overlays environment-specific patches — keeping everything DRY (Don't Repeat Yourself).

GitOps Workflow – End to End

1. Developer pushes application code to app-repo/main.
2. CI pipeline builds a Docker image: myrepo/webapp:abc1234.
3. CI pipeline opens an automated PR on k8s-manifests updating the image tag in the production overlay.
4. A team member reviews and merges the PR.
5. ArgoCD detects the change in k8s-manifests/overlays/production.
6. ArgoCD applies the updated Deployment — Kubernetes performs a rolling update.
7. ArgoCD's UI shows the application as "Synced" and "Healthy".

Handling Rollbacks in GitOps

A rollback is simply a Git operation:

# Option 1: Revert the last commit on the manifests repo
git revert HEAD
git push

# Option 2: Via ArgoCD UI
# Click the application → History → Select previous sync → Rollback

# Option 3: Via ArgoCD CLI
argocd app rollback webapp 3

ArgoCD immediately applies the reverted state. The cluster returns to the previous working version in seconds.

Security Benefits of GitOps

• No cluster credentials in CI: The pull model means CI systems never need kubectl access to production.
• Full audit trail: Every production change maps to a Git commit with an author, timestamp, and message.
• Mandatory code review: Pull request gates ensure no change reaches production without approval.
• Self-healing: If someone makes an unauthorized manual change to the cluster, GitOps automatically reverts it.

Real-World Example

A fintech company manages 15 microservices across three Kubernetes clusters (dev, staging, production). Every deployment starts as a PR on the manifests repository. Automated checks verify the YAML is valid. A senior engineer reviews and approves. ArgoCD applies the change. The entire history of what ran in production — every image version, every config change — lives in Git and is fully auditable for compliance purposes.

Summary

• GitOps makes Git the single source of truth for both application code and infrastructure state.
• The pull model is more secure than the push model — clusters pull from Git, not the other way around.
• ArgoCD and Flux are the leading GitOps operators for Kubernetes.
• Drift detection and self-healing ensure the cluster always matches the desired Git state.
• Rollbacks are simple Git operations — no special scripts or manual steps required.
• GitOps provides a complete, tamper-proof audit trail of all production changes.