GitOps er en tilgang til continuous deployment (især for Kubernetes), hvor Git er den eneste kilde til sandhed for den ønskede tilstand af infrastruktur og applikationer, og en automatiseret agent kontinuerligt afstemmer den faktiske tilstand til at matche Git. Ændringer foretages via Git, og systemet trækker og anvender dem.
GitOps-modellen
Git holds the DESIRED STATE (declarative configs: Kubernetes manifests, Helm charts, etc.):
→ an AGENT in the cluster continuously COMPARES actual state vs Git (desired state)
→ it RECONCILES: automatically applies changes to make reality match Git
→ to deploy/change: commit to Git → the agent detects and applies it (PULL-based)
→ Git = single source of truth; the system continuously converges to it.
Push vs pull-deployment
TRADITIONAL CI/CD (push) → the pipeline PUSHES changes TO the cluster (CI has cluster
credentials, runs kubectl apply)
GITOPS (pull) → an agent INSIDE the cluster PULLS from Git and applies changes:
✓ cluster credentials stay IN the cluster (more secure — CI doesn't need them)
✓ continuous reconciliation (drift is auto-corrected)
→ Tools: ArgoCD, Flux (Kubernetes GitOps operators).
Fordele
✓ Git as SOURCE OF TRUTH — all changes via Git (versioned, reviewed, audited, history)
✓ DECLARATIVE — describe the desired state; the system makes it so (and KEEPS it so)
✓ AUTO-RECONCILIATION — drift (manual changes) is detected and corrected automatically
✓ Easy ROLLBACK — revert the Git commit → the system reverts to that state
✓ SECURITY — pull-based (no external system needs cluster credentials)
✓ Visibility — Git history = deployment history; clear audit trail
Hvorfor det betyder noget
At forstå GitOps er værdifuld knowledge på seniorniveau, fordi det er en vigtig, stadig mere udbredt tilgang til continuous deployment (især for Kubernetes), så det er nyttigt for moderne cloud-native delivery.
GitOps-kernmodellen — Git som den eneste kilde til sandhed for ønsket tilstand, med en automatiseret agent, der kontinuerligt afstemmer faktisk tilstand til at matche Git — repræsenterer en ren, kraftfuld tilgang: du ændrer systemer ved at committe til Git, og systemet trækker og anvender ændringerne, hvor virkeligheden kontinuerligt konvergerer mod den deklarerede ønskede tilstand.
At forstå push vs pull-distinktionen er nøglen: traditionel CI/CD pusher ændringer til clusteret (hvilket kræver, at CI har cluster-credentials), mens GitOps bruger en pull-model, hvor en agent inden i clusteret trækker fra Git — hvilket er mere sikkert (cluster-credentials bliver i clusteret; intet eksternt CI-system har brug for dem) og giver kontinuerlig afstemning (automatisk korrektion af drift).
At forstå fordelene — Git som kilde til sandhed (alle ændringer versioneret, reviewet, audit'et via Gits historie), den deklarative model (beskrivelse af ønsket tilstand og at få systemet til at vedligeholde det), automatisk afstemning (detektering og korrektion af drift fra manuelle ændringer), let rollback (gendannelse af en Git-commit gendanner systemet), forbedret sikkerhed (pull-baseret) og synlighed (Git-historie som deployment-historie) — forklarer, hvorfor GitOps er overbevisende for Kubernetes-deployment.
At kende værktøjerne (ArgoCD, Flux) giver praktisk kontekst.
GitOps bliver i stigende grad vedtaget til cloud-native, Kubernetes-baseret delivery, hvilket repræsenterer en moderne udvikling af CD-praksis.
Da GitOps er en vigtig, voksende tilgang til continuous deployment (med rigtige fordele inden for sikkerhed, audit-sporing, drift-korrektion og rollback) især for Kubernetes, og da forståelse af dens model, pull-baseret tilgang og dens fordele er værdifuld for moderne delivery, er forståelse af GitOps værdifuld knowledge på seniorniveau for cloud-native continuous deployment — et moderne, stadig mere relevant CD-paradigme, der afspejler udviklingen af deployment-praksis, nyttigt for teams, der anvender Kubernetes og deklarative, Git-drevne operationer.