GitOps mit ArgoCD und Helm: Auditierbare Releases für regulierte Branchen

Ein Prüfer will wissen, welche Software-Version an einem bestimmten Tag in Produktion lief und wer sie freigegeben hat. In vielen Teams beginnt dann eine mühsame Suche in Logs, Tickets und Erinnerungen. Mit GitOps steht die Antwort jederzeit in Git, und ein fehlerhaftes Release ist mit einem einzigen Revert zurückgenommen.

Das Wichtigste in Kürze

• Mit GitOps steht der gewünschte Zustand jedes Kubernetes-Clusters in Git, und ArgoCD korrigiert jede Abweichung automatisch.
• Ohne direkten Cluster-Zugriff ist jede Änderung an laufender Infrastruktur ein geprüfter, gemergter Commit.
• Promotion und Rollback werden zu Git-Operationen: ein Merge oder ein Revert, ohne eigenes Tooling.
• Security-Scans gehören in die CI-Pipeline, bevor eine Änderung überhaupt zum Deployment vorgeschlagen wird.
• Der Audit-Trail entsteht aus dem Deployment-Modell selbst und muss nicht als separates System gepflegt werden.

Warum Push-basierte Deployments bei Audits scheitern

Ich sehe immer noch Teams, die per kubectl apply vom Laptop nach Kubernetes deployen oder eine CI-Pipeline bei jedem Merge direkt in einen Cluster pushen lassen. Beides funktioniert, bis jemand die Frage stellt, die jede regulierte Umgebung irgendwann stellt: Was lief an einem bestimmten Datum in Produktion, wer hat es freigegeben, und können Sie das belegen?

Bei Push-basierten Deployments lautet die ehrliche Antwort meist "wir sind uns nicht ganz sicher". Der tatsächliche Cluster-Zustand und der dokumentierte Soll-Zustand driften auseinander, sobald ein manuelles kubectl edit oder ein Notfall-Hotfix die Pipeline umgeht.

Auditoren akzeptieren "schauen Sie in die Deployment-Logs" nicht als befriedigende Antwort, und ich sollte das auch nicht.

So funktioniert GitOps mit ArgoCD und Helm

Die Lösung, zu der ich greife, ist GitOps. Der gewünschte Zustand jedes Clusters lebt in einem Git-Repository. Ein Reconciliation-Controller, bei mir ArgoCD, vergleicht diesen deklarierten Zustand kontinuierlich mit dem, was im Cluster läuft, und korrigiert jede Abweichung automatisch.

Helm-Charts und Values-Dateien pro Umgebung

Helm-Charts templaten die Kubernetes-Manifeste. Ein einzelnes Chart beschreibt eine Anwendung, und umgebungsspezifische Values-Dateien liefern die Unterschiede zwischen Dev, Staging und Produktion.

Die eine Regel: kein direkter Cluster-Zugriff

Nichts erreicht einen Cluster außer über eine Änderung in Git, und jede Änderung in Git ist ein geprüfter Merge Request. Genau diese eine Einschränkung macht aus "vertrauen Sie mir" ein "hier ist der Commit".

Promotion von Staging nach Produktion

Mit dieser Struktur wird die Promotion eines Releases zwischen Umgebungen vom Deploy-Skript zur Git-Operation. Dieselbe Chart-Version wandert von Staging nach Produktion, indem eine Änderung an der Values-Datei gemerged wird, die den Image-Tag oder die Konfiguration für diese Umgebung anhebt.

Rollback per git revert

Ein Rollback ist ein git revert, kein Gerangel um die vorherige Helm-Release-Nummer. Weil ArgoCD kontinuierlich abgleicht, folgt der Cluster in dem Moment, in dem der Revert landet. Dafür braucht es weder separates Rollback-Tooling noch einen manuellen Eingriff.

Die Commit-Historie als Release-Historie

Die Promotion-Historie ist damit die Commit-Historie. Ich kann auf einen Pull Request zeigen und genau belegen, wann eine Version Produktion erreicht hat und wer sie freigegeben hat.

Security-Stages in der CI-Pipeline

GitOps regelt, was nach der Freigabe einer Änderung passiert. Ich will trotzdem Vertrauen in das haben, was vorgeschlagen wird.

Deshalb laufen Build, Test und Security-Scanning als eigene Stages in GitLab CI, bevor ein Image oder Chart überhaupt für eine Änderung an der Values-Datei infrage kommt. Dependency-Scanning, Container-Image-Scanning und Policy-Checks gaten die Pipeline.

Gebaute Artefakte landen in einer zentralen Registry und werden über einen unveränderlichen Tag referenziert, nie über latest. Was in Git beschrieben ist, entspricht damit exakt dem, was deployt wird, und es gibt keinen Zweifel, welcher Build gerade läuft.

Was das für Ihr Unternehmen heißt

In regulierten Branchen kommt die Frage "Wer hat was wann freigegeben?" mit Sicherheit, spätestens im nächsten Audit. Eine unsichere Antwort kostet dann Zeit und Vertrauen, und die Rekonstruktion bindet genau die Leute, die eigentlich an Ihrem Produkt arbeiten sollten. Dazu kommt ein Klumpenrisiko: Wenn nur einzelne Personen wissen, was wo läuft, fehlt dieses Wissen genau dann, wenn diese Personen im Urlaub sind oder das Unternehmen verlassen.

Mit GitOps entsteht dieser Nachweis als Nebenprodukt der täglichen Arbeit. Ihr Team dokumentiert nichts zusätzlich, weil jede Änderung ohnehin als geprüfter Commit entsteht. Releases werden außerdem planbarer, denn ein fehlerhaftes Update ist mit einem Revert zurückgenommen, ohne manuelle Notfallaktion im Cluster. Wie ich Release-Prozesse und Deployments auf AWS aufsetze, beschreibe ich auf der Seite zu AWS-Kosten und Skalierung.