GitOps in der Praxis: Ein reproduzierbarer Deploy-Flow

GitOps klingt nach einem weiteren Buzzword, ist aber im Kern nur die konsequente Anwendung eines alten Prinzips: Der gewünschte Zustand eines Systems wird deklarativ beschrieben, in Git versioniert – und ein Automat sorgt dafür, dass die Realität diesem beschriebenen Zustand entspricht.

Git als einzige Quelle der Wahrheit

Der entscheidende Perspektivwechsel: Nicht der laufende Cluster ist die Wahrheit, sondern das Repository. Weicht die Realität ab – weil jemand von Hand eingegriffen hat – gleicht der Automat sie wieder an oder meldet den Drift. Damit verschwindet die häufigste Quelle unerklärlicher Zustände: die unsichtbare, undokumentierte Handänderung.

Wie der Flow konkret aussieht

1. 1Eine Änderung wird als Pull Request gegen das Repository geöffnet.
2. 2Review und automatisierte Checks laufen – die Änderung ist sichtbar und diskutierbar.
3. 3Nach dem Merge übernimmt der Reconciler und bringt die Umgebung in den neuen Zustand.
4. 4Die gesamte Historie steht in Git – ein Rollback ist ein Revert, kein Krisenprojekt.

# Rollback ist im GitOps-Modell unspektakulaer:
git revert <commit>   # den fehlerhaften Zustand zuruecknehmen
git push              # der Reconciler stellt den alten Zustand wieder her

Das Ziel ist ein Deploy, der so langweilig ist, dass niemand mehr Angst davor hat, ihn freitagnachmittags zu machen.

Der eigentliche Gewinn

GitOps macht Deployen nicht nur sicherer, sondern auch demokratischer: Jeder im Team sieht dieselbe Wahrheit, jede Änderung ist nachvollziehbar, und das Wissen darüber, wie die Produktion aussieht, steckt nicht mehr in einzelnen Köpfen. Das ist Reproduzierbarkeit, angewandt auf den Weg in die Produktion.