GitOps
debt(d7/e7/b7/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note automated=no and tools like argocd/flux only catch misuse (e.g. drift, manual kubectl apply) at runtime after the fact — no static analysis catches whether you're following GitOps patterns. Silent failures like reconciliation breakdowns only surface through monitoring/alerting gaps, not build-time checks.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix says 'store all infrastructure and application configuration in git — deployments are triggered by git commits, not manual commands; ArgoCD or Flux watches the repo and applies changes.' Migrating from push-based CI/CD or manual ops to a full GitOps model requires restructuring deployment pipelines, separating app and config repos, setting up secret management (Vault/sealed-secrets), and establishing alerting for reconciliation failures — a cross-cutting change across multiple teams and repositories.
Closest to 'strong gravitational pull' (b7). GitOps, once adopted, shapes every future infrastructure change: all changes must go through Git, reconciliation must be monitored, secrets management must be handled externally, and emergency fixes must be immediately committed or they'll be reverted. This imposes a persistent workflow tax on every operator and developer touching infrastructure, making it a strong architectural gravity well.
Closest to 'serious trap' (t7). The misconception field explicitly states: 'GitOps is just CI/CD — traditional CI/CD pushes changes; GitOps pulls from Git.' A competent developer familiar with CI/CD will assume GitOps is just automated deployment pipelines, missing the pull model, continuous reconciliation, and automatic drift correction. The common_mistakes reinforce this — manual emergency fixes being silently reverted at the next reconciliation cycle is a particularly dangerous surprise for operators accustomed to push-based workflows.
Also Known As
TL;DR
Explanation
GitOps applies version control workflows to operations. The desired state is declared in Git; an operator (ArgoCD, Flux) detects drift between Git state and cluster state and reconciles automatically. Benefits: every change is audited in Git history, rollback is git revert, drift is automatically corrected. Works naturally with Kubernetes (ArgoCD, Flux) but the principle applies to any declarative infrastructure. Contrast with push-based CI/CD where the pipeline pushes changes to the environment.
Diagram
flowchart LR
DEV[Developer] -->|PR merged| GIT[(Git Repo<br/>source of truth)]
GIT -->|webhook| ARGO[ArgoCD / Flux<br/>continuous sync]
ARGO -->|detect diff| DIFF{Diff vs
cluster state?}
DIFF -->|in sync| OK[No action]
DIFF -->|drift detected| SYNC[Apply desired state<br/>auto-reconcile]
SYNC --> CLUSTER[K8s Cluster]
MANUAL[Manual kubectl<br/>change] -->|overridden| CLUSTER
ARGO -.->|reverts manual change| CLUSTER
style GIT fill:#6e40c9,color:#fff
style OK fill:#238636,color:#fff
style SYNC fill:#1f6feb,color:#fff
style MANUAL fill:#f85149,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Putting secrets in Git — GitOps repos must be public or at least team-accessible; secrets go in Vault or sealed-secrets.
- Not separating app code repo from config/manifests repo — mixing them makes it hard to track who changed what.
- No notifications when reconciliation fails — GitOps failures are silent without alerting.
- Manual emergency fixes without immediately committing to Git — the operator reverts the manual fix at the next reconciliation cycle.
Avoid When
- Small teams or solo projects where Git-driven deployment adds process overhead with no coordination benefit.
- Highly stateful workloads where the desired state is hard to express declaratively in a Git repo.
- Teams without existing CI/CD maturity — GitOps requires solid automation foundations to work reliably.
- Secrets managed in plain Git — GitOps requires a secrets management strategy; never commit credentials.
When To Use
- Kubernetes deployments where Argo CD or Flux can reconcile cluster state to the Git-declared desired state.
- Multi-team environments where infrastructure changes need auditability, review, and rollback via Git history.
- Disaster recovery — the entire desired cluster state is in Git and can be restored by re-applying it.
- Compliance environments that require an immutable audit trail of every infrastructure change.
Code Examples
# Push-based CI/CD — no audit trail, drift possible:
# .github/workflows/deploy.yml
steps:
- run: kubectl apply -f k8s/
# Manual kubectl change on prod? Not recorded, not reverted
# 'Who changed the replica count?' → no one knows# GitOps with ArgoCD — declarative, audited, self-healing:
# k8s/deployment.yaml committed to git:
apiVersion: apps/v1
kind: Deployment
spec:
replicas: 3 # Desired state in Git
# ArgoCD watches the repo:
# Manual kubectl scale → ArgoCD detects drift → reverts to 3 replicas
# All changes via PR → full audit trail in git history