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.
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?
In der Praxis übergibt die CI-Pipeline an GitOps über einen Git-Commit: Sie 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.
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.
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