CI/CD und GitOps konkurrieren nicht — GitOps ersetzt nur den Deployment-Teil (CD): CI/CD baut, testet und erzeugt Artefakte und „pusht“ klassisch das Deployment. GitOps macht den Zustand deklarativ in Git zur Quelle, und ein Agent (ArgoCD, Flux) „pullt“ ihn ins Cluster und korrigiert Drift automatisch. Continuous Integration bleibt in jedem Fall nötig; GitOps übernimmt danach das pull-basierte, auditierbare Deployment.
Die Pipeline sagt dem Cluster, was es tun soll — und führt das Deployment selbst aus.
Der Cluster liest den Soll-Zustand aus Git und stellt ihn selbst her — kontinuierlich und auditierbar.
Worin unterscheiden sich CI/CD und GitOps konkret?
Der Kernunterschied liegt im Deployment-Mechanismus: Klassisches CI/CD pusht aktiv — die Pipeline hält Cluster-Credentials und führt das Deployment selbst aus. GitOps pullt — ein Agent im Cluster beobachtet Git und stellt den deklarierten Zustand selbstständig her. Die Tabelle zeigt, was das für Verantwortlichkeiten, Sicherheit und Drift-Verhalten bedeutet.
Wie sieht der GitOps-Workflow in der Praxis aus?
Der GitOps-Workflow übergibt von CI/CD an ein pull-basiertes, deklaratives Deployment über einen Git-Commit: Die CI-Pipeline baut und testet das Container-Image, schreibt das neue Image-Tag ins Config-Repository — und ist damit fertig. Den Rest erledigt der Agent im Cluster. Die Pipeline braucht keinerlei Cluster-Credentials mehr.
Das Beispiel zeigt die Übergabe konkret: Links die GitLab-CI-Pipeline im Anwendungs-Repository, die das Image baut und den neuen Soll-Zustand committet. Rechts das Config-Repository, das ArgoCD oder Flux beobachten — die Änderung des newTag löst das Deployment aus, ganz ohne aktiven Push ins Cluster.
stages: [build, update-manifest]
build-image:
stage: build
script:
- docker build -t $REGISTRY/shop/api:$CI_COMMIT_SHORT_SHA .
- docker push $REGISTRY/shop/api:$CI_COMMIT_SHORT_SHA
update-manifest:
stage: update-manifest
script:
# Soll-Zustand ins Config-Repo committen —
# keine Cluster-Credentials in der CI
- git clone https://git.example.com/platform/shop-config.git
- cd shop-config
- yq -i '.images[0].newTag = env(CI_COMMIT_SHORT_SHA)'
overlays/prod/kustomization.yaml
- git commit -am "shop/api -> $CI_COMMIT_SHORT_SHA"
- git push origin mainapiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
images:
- name: registry.example.com/shop/api
newTag: a1b2c3d # von der CI committet
# Der Agent im Cluster zieht die Änderung selbst:
$ argocd app get shop-prod
Health Status: Healthy
Sync Status: Synced to main (1f4e5d6)
Last Sync: Succeeded (auto, prune, selfHeal)Welche Stolpersteine gibt es beim Umstieg auf GitOps?
Die häufigsten Fehler beim Umstieg sind organisatorisch, nicht technisch: Anwendungs- und Config-Repository werden nicht getrennt, Secrets landen im Klartext in Git, und Rollbacks werden weiter in Pipeline-Logik gedacht statt in Git-Historie. Vier Punkte, die in Projekten regelmäßig auffallen:
App- und Config-Repo nicht trennen
Liegen Manifeste im Anwendungs-Repository, löst jeder Code-Commit ein Deployment aus und Infrastruktur-Änderungen lassen sich nicht separat reviewen. Ein eigenes Config-Repository pro Plattform oder Team entkoppelt Release-Takt und Deployment-Freigabe.
Image-Tags manuell pflegen
Wer nach jedem Build von Hand das Tag im Config-Repo ändert, baut sich eine manuelle Brücke mitten in die Automatisierung. Entweder committet die CI das Tag selbst (wie im Beispiel oben) oder ein Image Updater (ArgoCD Image Updater, Flux Image Automation) beobachtet die Registry.
Secrets im Klartext in Git
Git als Source of Truth heißt nicht, Datenbank-Passwörter ins Repository zu legen. Etabliert haben sich SOPS-verschlüsselte Secrets, Sealed Secrets oder External Secrets mit einem Vault als Backend — die Wahl sollte vor der ersten produktiven Anwendung feststehen.
Rollbacks in Pipeline-Logik denken
Ein GitOps-Rollback ist ein git revert, keine erneute Pipeline-Ausführung. Teams, die für den Notfall weiter eine „Deploy-alte-Version“-Pipeline mit Cluster-Zugriff pflegen, unterlaufen das Pull-Modell und schaffen einen zweiten, schlecht auditierbaren Deployment-Pfad.
Für Industrieumgebungen kommt ein struktureller Vorteil dazu: Edge-Cluster in Werken hängen oft hinter restriktiven Firewalls oder laufen air-gapped. Das Pull-Prinzip dreht die Verbindungsrichtung um — der Cluster holt sich seinen Soll-Zustand selbst, keine Pipeline muss von außen ins OT-Netz. Welches GitOps-Tool dafür passt, vergleicht ArgoCD vs. Flux.
Welche Nachteile und Grenzen hat GitOps?
GitOps ist kein Selbstzweck — der Gewinn an Sicherheit und Auditierbarkeit wird mit zusätzlicher Komplexität erkauft. Vier Grenzen, die vor der Einführung realistisch eingeplant gehören:
Höhere Einstiegskomplexität
Config-Repository, ein Agent im Cluster und ein sauberes Branching-Modell müssen erst stehen. Teams ohne Kubernetes-Erfahrung zahlen eine spürbare Lernkurve, bevor der erste produktive Sync läuft.
Secret-Management wird zur Pflicht
Git als Source of Truth verträgt keine Klartext-Secrets. SOPS, Sealed Secrets oder External Secrets mit Vault sind kein Add-on, sondern Voraussetzung — diese Entscheidung steht am Anfang, nicht am Ende.
Config-Sprawl bei vielen Umgebungen
Jede Umgebung und jedes Cluster lebt als eigener deklarativer Zustand in Git. Ohne Kustomize-Overlays oder eine durchdachte Repo-Struktur wächst der Pflegeaufwand mit jeder Umgebung.
Overkill bei einfachen Deployments
Für eine einzelne VM, eine Server-App ohne Kubernetes oder kleine Setups bringt das Pull-Modell wenig Vorteil. Dort bleibt klassisches Push-CD die pragmatischere, schnellere Wahl.
Die Faustregel: GitOps zahlt sich ab Kubernetes, Multi-Cluster-Setups und regulierten Branchen aus — dort, wo Audit-Trail und automatische Reconciliation den Mehraufwand rechtfertigen. Welches GitOps-Tool dazu passt, vergleicht ArgoCD vs. Flux.
Was ist der Unterschied zwischen CI/CD und GitOps?
CI/CD beschreibt die automatisierte Kette aus Build, Test und Auslieferung — klassisch „pusht" die Pipeline das Deployment aktiv ins Ziel. GitOps dreht das CD um: Der gewünschte Zustand steht deklarativ in Git, und ein Agent (ArgoCD, Flux) „pullt" ihn und gleicht das Cluster kontinuierlich ab. GitOps ersetzt also nicht CI/CD, sondern den CD-Teil durch ein pull-basiertes, deklaratives Modell.
Ist GitOps Push oder Pull?
GitOps ist pull-basiert: Ein im Cluster laufender Agent beobachtet das Git-Repository und zieht Änderungen, statt dass eine externe Pipeline Zugangsdaten zum Cluster braucht und aktiv pusht. Das verbessert die Sicherheit (keine Cluster-Credentials in der CI) und ermöglicht automatische Drift-Korrektur.
Ersetzt GitOps die CI/CD-Pipeline?
Nein — GitOps ersetzt nur den Deployment-Teil (CD). Continuous Integration (Build, Test, Security-Scans, Artefakt- und Image-Erstellung) bleibt nötig und läuft weiterhin in Jenkins, GitLab CI oder GitHub Actions. Die CI committet anschließend den neuen gewünschten Zustand nach Git, den GitOps übernimmt.
Wie spielen CI/CD und GitOps konkret zusammen?
Typischer Ablauf: 1) CI baut und testet, erzeugt ein Container-Image. 2) Die Pipeline aktualisiert das Image-Tag im Git-Repository (Config-Repo). 3) Der GitOps-Agent erkennt die Änderung und rollt sie ins Cluster aus. So bleiben Build-Logik und Deployment-Zustand sauber getrennt.
Wann ist GitOps gegenüber klassischem Push-CD sinnvoll?
GitOps spielt seine Stärken bei Kubernetes, Multi-Cluster-Setups und regulierten Branchen aus — wegen Audit-Trail über Git, automatischer Reconciliation und fehlender Cluster-Credentials in der CI. Bei einfachen, nicht-kubernetes-basierten Deployments kann klassisches Push-CD weiterhin die pragmatischere Wahl sein.
Was ist ein Config-Repository und warum braucht GitOps eines?
Das Config-Repository hält den gewünschten Cluster-Zustand — Kubernetes-Manifeste, Kustomize-Overlays oder Helm-Values — getrennt vom Anwendungscode. Die Trennung verhindert, dass jeder Code-Commit ein Deployment auslöst, und erlaubt eigene Review- und Freigabeprozesse für Infrastruktur-Änderungen. Der GitOps-Agent beobachtet ausschließlich dieses Repository.
Wie funktionieren Rollbacks mit GitOps?
Ein Rollback ist ein git revert auf dem Config-Repository: Der alte Zustand wird als neuer Commit deklariert, der Agent gleicht das Cluster automatisch an. Es braucht keine separate Rollback-Pipeline und keinen manuellen Cluster-Zugriff — und die Git-Historie dokumentiert nachvollziehbar, wer wann was zurückgerollt hat.
Was ist ein wesentlicher Nachteil von GitOps?
Der größte Nachteil ist die zusätzliche Komplexität: GitOps verlangt ein separates Config-Repository, einen Agenten im Cluster und eine durchdachte Secret-Strategie (SOPS, Sealed Secrets, External Secrets). Bei vielen Umgebungen wächst die Config-Pflege spürbar, und für einfache, nicht-kubernetes-basierte Deployments ist klassisches Push-CD oft die pragmatischere Wahl. GitOps zahlt sich erst ab Kubernetes, Multi-Cluster oder regulierten Branchen wirklich aus.
Ist Git ein CI/CD-Tool?
Nein — Git ist ein Versionskontrollsystem, kein CI/CD-Tool. CI/CD-Werkzeuge wie Jenkins, GitLab CI oder GitHub Actions setzen auf Git auf: Ein Commit oder Merge-Request löst die Pipeline aus. Bei GitOps geht Git einen Schritt weiter und wird zur deklarativen Source of Truth für den gewünschten Cluster-Zustand — das Deployment selbst übernimmt aber weiterhin ein Agent wie ArgoCD oder Flux.
Was ist CI/CD einfach erklärt?
CI/CD ist die automatisierte Kette von der Code-Änderung bis zur lauffähigen Anwendung. Continuous Integration (CI) baut den Code, führt Tests und Security-Scans aus und erzeugt ein Artefakt (z. B. ein Container-Image). Continuous Delivery/Deployment (CD) bringt dieses Artefakt automatisiert in die Zielumgebung. Ziel ist, manuelle Schritte zu eliminieren und Software schneller, häufiger und zuverlässiger auszuliefern.
Verwandte Artikel
ArgoCD vs. Flux: GitOps-Tools im Vergleich 2026
Welches GitOps-Tool für Kubernetes — ArgoCD oder Flux?
Jenkins vs. GitLab vs. GitHub Actions vs. Azure DevOps
CI/CD-Plattformen im ehrlichen Vergleich.
IndustrialFlow: industrielles CI/CD als eigenes Werkzeug
GitOps und CI/CD air-gap-fähig für die OT.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance