DMoove Blog

Warum DevOps ohne GitOps unvollständig bleibt

Geschrieben von Yannick Tresch | Oct 19, 2025 1:10:46 PM

DevOps gibt dir die Arbeitsweise, GitOps liefert die Umsetzung. Während viele Teams bei halbautomatisierten Prozessen steckenbleiben, schließt GitOps mit Pull-basierten Deployments und Git als Single Source of Truth den Kreis.

Die Antwort auf einen Blick

  • GitOps erweitert DevOps durch deklarative Infrastruktur und automatische Synchronisierung

  • Pull-Ansatz (FluxCD, ArgoCD) sorgt für Selbstheilung statt manueller Fehlerkorrektur

  • Git wird zur einzigen Wahrheitsquelle für Code und Infrastruktur

  • Automatisierung ersetzt manuelle Deployments und verhindert Inkonsistenzen

Was du in der Praxis siehst

Du kennst das wahrscheinlich: Teams sagen "wir machen DevOps", aber der Code liegt nur in Git.

Keine Pipeline. Keine Automatisierung.

Jemand zieht sich eine lokale Kopie, deployt manuell und hofft auf Konsistenz. Funktioniert nicht.

DevOps gibt dir die Arbeitsweise. GitOps schließt den Kreis.

Warum halbautomatisiertes DevOps scheitert

Viele Teams bleiben bei der DevOps-Implementierung auf halbem Weg stecken.

Der Infrastruktur-Code liegt in Git. Aber es fehlt die Pipeline, die ihn automatisch ausrollt.

Das Ergebnis? Manuelle Deployments. Inkonsistente Stände. Infrastrukturteile, die plötzlich verschwinden, weil jemand lokal was geändert hat.

DevOps ohne Automatisierung ist wie ein Auto ohne Motor. Sieht gut aus, fährt aber nicht.

Kernpunkt: Ohne vollständige Automatisierung bleibt DevOps ein unvollständiges Konzept.

Wie Pull-basiertes GitOps funktioniert

Hier wird GitOps interessant.

Beim klassischen Push-Ansatz mit Tools wie Terraform oder CDK pusht deine CI/CD-Pipeline Änderungen in die Infrastruktur. Wenn die Pipeline fehlschlägt, bleibt der alte Stand stehen.

Beim Pull-Ansatz mit FluxCD oder ArgoCD dreht sich das um.

Das System holt sich kontinuierlich den gewünschten Zustand aus Git. Wenn was nicht stimmt, korrigiert es sich selbst.

Ein Netzwerkfehler? Kein Problem. Das System versucht es einfach weiter, bis es den Git-Stand erreicht hat.

Eine manuelle Änderung in der Infrastruktur? ArgoCD erkennt die Differenz und setzt sie zurück.

Das ist Selbstheilung auf System-Ebene.

Kernpunkt: Pull-basierte Systeme eliminieren manuelle Fehlerkorrektur durch kontinuierliche Synchronisierung.

Git als Single Source of Truth einrichten

Die Antwort auf "wie mache ich DevOps richtig?" ist eigentlich simpel.

Was in Git eingecheckt ist, muss in der Infrastruktur sein. Punkt.

Nicht nur der Application-Code. Auch die Infrastruktur. Die Helm Charts. Die Kubernetes-Konfigurationen.

Alles deklarativ. Alles versioniert. Alles nachvollziehbar.

Jede Änderung läuft über einen Pull Request. Peer-Reviews inklusive. Audit-Trail automatisch.

So wird Git zur einzigen Wahrheitsquelle für dein gesamtes System.

Kernpunkt: Git als zentrale Wahrheitsquelle eliminiert Inkonsistenzen zwischen Code und Infrastruktur.

Welche Tools du brauchst

Für klassische Push-Pipelines nutze ich CDK, Pulumi oder Terraform. Die laufen auf GitLab Runners oder GitHub Actions.

Für Kubernetes setze ich auf FluxCD. Weniger grafisch als ArgoCD, aber genauso mächtig.

Dazu kommen Helm Charts für Paketierung, Kustomize für Value-Anpassungen und External Secrets Manager für sichere Secret-Verwaltung.

Secrets gehören nicht in Git. Niemals.

GitOps hat sich in den letzten Jahren vom experimentellen Ansatz zum etablierten Standard entwickelt. Tools wie FluxCD und ArgoCD haben beide den CNCF Graduation-Status erreicht.

Das zeigt: GitOps ist erwachsen geworden.

Kernpunkt: Die Tool-Landschaft ist ausgereift und produktionsbereit.

Wie DevOps durch GitOps komplett wird

DevOps gibt dir die Prinzipien: Zusammenarbeit, Automatisierung, kontinuierliche Verbesserung.

GitOps gibt dir die Implementierung. Den deklarativen Ansatz. Die automatische Synchronisierung. Die Selbstheilung.

Natürlich gibt es Ausnahmen. Das initiale Aufsetzen von Kubernetes bleibt ein Push-Vorgang. Manche Dinge kannst du nicht pullen.

Aber für alles andere gilt: Was in Git steht, läuft in der Infrastruktur.

So wird DevOps rund.

Nicht durch mehr Tools oder komplexere Prozesse, sondern durch konsequente Automatisierung und eine einzige Wahrheitsquelle.

Git als Fundament. Pull als Mechanismus. Automatisierung als Ergebnis.

Das ist GitOps. Und das macht DevOps endlich komplett.

Häufige Fragen zu GitOps

Was ist der Hauptunterschied zwischen DevOps und GitOps?
DevOps ist eine Arbeitsweise und Kultur, GitOps ist eine spezifische Implementierung davon. GitOps nutzt Git als Single Source of Truth für Infrastruktur und Anwendungen und setzt auf deklarative Konfigurationen mit automatischer Synchronisierung.

Warum ist der Pull-Ansatz besser als der Push-Ansatz?
Beim Pull-Ansatz holt sich das System kontinuierlich den gewünschten Zustand aus Git. Wenn ein Deployment fehlschlägt oder manuelle Änderungen vorgenommen werden, korrigiert sich das System automatisch. Beim Push-Ansatz bleibt der alte Stand bei Fehlern einfach stehen.

Brauche ich Kubernetes für GitOps?
Nein, aber GitOps funktioniert besonders gut mit Kubernetes. Die deklarative Natur von Kubernetes passt perfekt zum GitOps-Ansatz. Du kannst GitOps-Prinzipien aber auch mit anderen Infrastructure-as-Code-Tools umsetzen.

Wie sichere ich Secrets in GitOps?
Secrets gehören niemals direkt in Git. Nutze Tools wie External Secrets Manager, Sealed Secrets oder Vault, um Secrets sicher zu verwalten und nur Referenzen in Git zu speichern.

Welches Tool soll ich wählen: FluxCD oder ArgoCD?
Beide sind ausgereift und CNCF-graduiert. ArgoCD bietet eine grafische Oberfläche und ist visueller. FluxCD ist schlanker und weniger grafisch. Beide erfüllen denselben Zweck, die Wahl hängt von deinen Präferenzen ab.

Was passiert bei einem Git-Ausfall?
Deine laufende Infrastruktur bleibt stabil. GitOps-Tools synchronisieren nur Änderungen. Wenn Git nicht erreichbar ist, läuft alles weiter wie bisher, nur neue Deployments werden pausiert bis Git wieder verfügbar ist.

Wie starte ich mit GitOps in einem bestehenden DevOps-Setup?
Beginne damit, deine Infrastruktur-Konfigurationen vollständig in Git zu versionieren. Baue dann Pipelines auf, die automatisch aus Git deployen. Schließlich wechsle zu Pull-basierten Tools wie FluxCD oder ArgoCD für kontinuierliche Synchronisierung.

Funktioniert GitOps auch für Legacy-Systeme?
Teilweise. GitOps funktioniert am besten mit cloud-nativen, containerisierten Anwendungen. Für Legacy-Systeme kannst du die Prinzipien anwenden (Git als Wahrheitsquelle, Automatisierung), aber die volle Pull-basierte Synchronisierung ist oft schwieriger umzusetzen.

Die wichtigsten Erkenntnisse

  • GitOps vervollständigt DevOps durch konsequente Automatisierung und Git als zentrale Wahrheitsquelle

  • Pull-basierte Tools wie FluxCD und ArgoCD ermöglichen Selbstheilung und eliminieren manuelle Fehlerkorrektur

  • Die vollständige Versionierung von Code und Infrastruktur in Git schafft Transparenz und Nachvollziehbarkeit

  • GitOps ist kein Trend mehr, sondern ein etablierter Standard mit ausgereiften, produktionsbereiten Tools

  • Der Übergang zu GitOps erfordert vollständige Automatisierung, nicht nur das Ablegen von Code in Git