GitOps oder direktes Deployment?
GitOps verbessert Nachvollziehbarkeit und Drift-Erkennung. Direktdeployment ist einfacher, wenn Team, Plattform und Änderungsvolumen klein sind.
Vom Commit bis zur Produktion
Der Delivery-Ablauf ähnelt einer kontrollierten Lieferkette: Code wird geprüft, verpackt, signiert, in einer Registry abgelegt und anschließend über GitOps in die Plattform gebracht.
Alltagstaugliche Ablaufbeschreibung
Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.
- Commit
- CI führt Tests und Scans aus
- Container Image entsteht
- Registry speichert Artifact
- Manifest/Helm wird aktualisiert
- Argo CD synchronisiert
- Kubernetes rollt aus
- Observability prüft Wirkung.
Fachlicher Ablauf
Eine geprüfte Änderung soll kontrolliert in Produktion gelangen. Fachlich zählt, dass der gewünschte Nutzen ausgeliefert wird, ohne Sicherheit, Stabilität oder Rückrollfähigkeit zu verlieren.
- Fachliches Ziel: Der Ablauf liefert ein fachlich eindeutiges und für Benutzer beziehungsweise Betrieb nachvollziehbares Ergebnis.
- Verantwortung: Jeder beteiligte Bereich entscheidet nur innerhalb seiner eigenen fachlichen Zuständigkeit.
- Sichtbares Ergebnis: Benutzer erhalten die neue Funktion schrittweise; bei Problemen kann die alte Version reproduzierbar wiederhergestellt werden.
Technischer Ablauf
Ein Commit startet Build, Tests, Security Scans und Artifact-Erzeugung. Das Image wird unveränderlich in der Registry gespeichert. GitOps übernimmt den gewünschten Deployment-Zustand; Kubernetes führt den Rollout mit Probes und kontrollierter Strategie aus.
- Daten und Schnittstellen: Daten werden an jeder Grenze validiert und nur über definierte APIs, Ports oder Events weitergegeben.
- Fehlerbehandlung: Fehler werden dort behandelt, wo ausreichender Kontext und Verantwortung vorhanden sind; Wiederholungen müssen sicher und nachvollziehbar bleiben.
- Technischer Nachweis: Geprüft werden Quality Gates, Image Digest, GitOps Sync, Pod Readiness, Error Rate und Rollback-Fähigkeit.
Zusammenspiel: Der fachliche Ablauf erklärt, warum etwas geschieht und welches Ergebnis zählt. Der technische Ablauf erklärt, wie dieses Ergebnis zuverlässig, sicher und beobachtbar umgesetzt wird.
Ausgangslage
Mehrere Teams liefern Änderungen aus, während Produktion reproduzierbar und auditierbar bleiben muss.
Die Entscheidung wird nicht nach Mode, sondern nach Qualitätszielen, Teamfähigkeit, Betriebsmodell und Fault Tolerance getroffen.
Welche Frage wird wirklich entschieden?
Nicht „Welche Technologie ist moderner?“, sondern: Welche Option erfüllt die geschäftlichen Anforderungen mit der geringsten dauerhaft beherrschbaren Komplexität?
- Welche Benutzerwirkung muss geschützt werden?
- Welche Änderungen erfolgen wie häufig?
- Wer betreibt und verantwortet die Lösung?
- Welche Fehler müssen toleriert werden?
Option A: GitOps
Stärken: Gute Passung für den beschriebenen CommerceOne-Kontext, wenn Voraussetzungen und Betriebsfähigkeit vorhanden sind.
Nachteile: Zusätzliche Technik erzeugt Lern-, Betriebs-, Sicherheits- und Upgrade-Aufwand.
Option B: Pipeline deployt direkt
Stärken: Häufig einfacher, schneller verständlich und mit weniger Betriebsfläche.
Nachteile: Kann bei Wachstum, mehreren Teams oder höheren Verfügbarkeitszielen Grenzen erreichen.
Bewertungskriterien
CommerceOne-Entscheidung
Empfehlung: GitOps – aber nur unter den dokumentierten Voraussetzungen. Die Alternative Pipeline deployt direkt bleibt bevorzugt, wenn Organisation oder Lastbild einfacher sind.
Die Entscheidung wird als ADR festgehalten und nach sechs Monaten anhand realer Betriebsdaten überprüft.
Wann ausdrücklich nicht?
- Wenn das Team die Betriebsfolgen nicht verantworten kann.
- Wenn die Anforderungen auch mit einer wesentlich einfacheren Lösung erfüllt werden.
- Wenn die Entscheidung nur durch Trend, Anbieterfolie oder Lebenslaufoptimierung begründet wird.
Security, Performance und Betrieb
Security: Neue Komponenten erweitern Trust Boundaries (Trust Boundaries), Rechte und Patch-Flächen.
Performance: Latenz und Durchsatz müssen am End-to-End-Ablauf gemessen werden.
Betrieb: Für jede Option braucht CommerceOne Ownership, Telemetrie, Runbook, Backup- und Upgrade-Plan.
Kosten und organisatorische Folgen
Kosten bestehen nicht nur aus Infrastruktur. Entscheidend sind Bereitschaft, Schulung, Störungen, Security Reviews, Versionspflege und verlorene Entwicklungszeit. Die einfachere Option gewinnt, solange der zusätzliche Nutzen der komplexeren Option diese dauerhaften Kosten nicht übersteigt.
Entscheidungsfragen
- Welche Annahme könnte die Empfehlung kippen?
- Welche Kennzahl zeigt nach dem Einsatz, ob die Entscheidung erfolgreich war?
- Welche Exit-Strategie besteht, falls sich GitOps nicht bewährt?
Merksatz
Die beste Enterprise-Entscheidung ist nicht die technisch mächtigste, sondern die dauerhaft verständliche und betreibbare Lösung für das konkrete Problem.