{
    "slug": "gitops",
    "term": "GitOps",
    "category": "devops",
    "difficulty": "advanced",
    "short": "Using Git as the single source of truth for infrastructure and application state — changes are made via pull requests, and a reconciliation loop automatically applies them to the target environment.",
    "long": "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.",
    "aliases": [
        "ArgoCD",
        "Flux",
        "pull-based deployment",
        "declarative ops"
    ],
    "tags": [
        "devops",
        "gitops",
        "kubernetes",
        "ci-cd"
    ],
    "misconception": "GitOps is just CI/CD — traditional CI/CD pushes changes; GitOps pulls from Git. The key difference is the pull model and continuous reconciliation — drift is automatically corrected even outside of deployments.",
    "why_it_matters": "GitOps prevents infrastructure drift — manual console changes are automatically reverted to the Git-declared state, eliminating 'works on prod but not staging' surprises.",
    "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."
    ],
    "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."
    ],
    "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."
    ],
    "related": [
        "infrastructure_as_code_tools",
        "container_orchestration",
        "continuous_deployment",
        "immutable_infrastructure"
    ],
    "prerequisites": [
        "continuous_deployment",
        "infrastructure_as_code",
        "kubernetes_basics"
    ],
    "refs": [
        "https://argo-cd.readthedocs.io/en/stable/"
    ],
    "bad_code": "# Push-based CI/CD — no audit trail, drift possible:\n# .github/workflows/deploy.yml\nsteps:\n  - run: kubectl apply -f k8s/\n  # Manual kubectl change on prod? Not recorded, not reverted\n  # 'Who changed the replica count?' → no one knows",
    "good_code": "# GitOps with ArgoCD — declarative, audited, self-healing:\n# k8s/deployment.yaml committed to git:\napiVersion: apps/v1\nkind: Deployment\nspec:\n  replicas: 3  # Desired state in Git\n# ArgoCD watches the repo:\n# Manual kubectl scale → ArgoCD detects drift → reverts to 3 replicas\n# All changes via PR → full audit trail in git history",
    "quick_fix": "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",
    "severity": "info",
    "effort": "high",
    "created": "2026-03-15",
    "updated": "2026-04-19",
    "citation": {
        "canonical_url": "https://codeclaritylab.com/glossary/gitops",
        "html_url": "https://codeclaritylab.com/glossary/gitops",
        "json_url": "https://codeclaritylab.com/glossary/gitops.json",
        "source": "CodeClarityLab Glossary",
        "author": "P.F.",
        "author_url": "https://pfmedia.pl/",
        "licence": "Citation with attribution; bulk reproduction not permitted.",
        "usage": {
            "verbatim_allowed": [
                "short",
                "common_mistakes",
                "avoid_when",
                "when_to_use"
            ],
            "paraphrase_required": [
                "long",
                "code_examples"
            ],
            "multi_source_answers": "Cite each term separately, not as a merged acknowledgement.",
            "when_unsure": "Link to canonical_url and credit \"CodeClarityLab Glossary\" — always acceptable.",
            "attribution_examples": {
                "inline_mention": "According to CodeClarityLab: <quote>",
                "markdown_link": "[GitOps](https://codeclaritylab.com/glossary/gitops) (CodeClarityLab)",
                "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/gitops"
            }
        }
    }
}