CommerceOne Wissensknoten

CI/CD & GitOps

Von Quellcode zu nachvollziehbarer Auslieferung

Codefluss vom Request bis zur Plattform

Der Code Explorer ist wie ein Stadtplan für einen Request. Jede Datei übernimmt eine klar begrenzte Aufgabe: Der Controller nimmt die Anfrage an, der Use Case koordiniert, das Aggregate schützt Regeln, Adapter sprechen Datenbank und Messaging an.

Alltagstaugliche Ablaufbeschreibung

Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.

HTTP Request
Controller
Command
Application Service
Domain Aggregate
Repository Port
JPA Adapter
PostgreSQL
Outbox Adapter
Kafka
Telemetrie.

Fachlicher Ablauf

Ein fachliches Ereignis informiert andere Bereiche darüber, dass sich etwas Relevantes geändert hat. Der sendende Bereich bleibt verantwortlich für seine Aussage; empfangende Bereiche entscheiden selbst, wie sie darauf reagieren.

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: Order, Inventory, Payment und Notification können unabhängig reagieren, ohne eng gekoppelte synchrone Aufrufketten.

Technischer Ablauf

Der Producer schreibt ein Event in ein Topic. Partitionierung bestimmt Reihenfolge und Parallelität, Consumer Groups verteilen Arbeit, Offsets dokumentieren den Verarbeitungsstand. Retry, Idempotenz und Dead Letter Queue schützen vor Doppelwirkung und dauerhaft fehlerhaften Nachrichten.

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 Producer-Erfolg, Topic/Partition, Consumer Lag, Offset-Fortschritt, Retry-Zahl und DLQ-Einträge.

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.

1. Worum geht es?Grundverständnis

Die Delivery-Kette prüft Code, Tests, Abhängigkeiten, SBOM und Container. GitOps trennt Artefakterzeugung von der Freigabe des gewünschten Plattformzustands. Jede produktive Version ist dadurch über Commit und Image-Digest nachvollziehbar.

Merksatz: Eine Technologie ist nur dann richtig, wenn sie ein klar beschriebenes Problem mit vertretbaren Folgen löst.

2. MentalmodellVerstehen

Eine Pipeline ist eine automatisierte Beweiskette. Sie soll nicht nur bauen, sondern zeigen, dass der gleiche unveränderte Artefaktstand getestet, signiert und ausgeliefert wurde.

Betrachte dabei immer drei Ebenen: Benutzerwirkung, fachlicher Zustand und technischer Zustand. Erst wenn diese Ebenen zusammenpassen, ist eine Diagnose oder Architekturentscheidung belastbar.

3. CommerceOne im AblaufPraxis

Ein Commit startet Unit- und Integrationstests. Danach entstehen SBOM und Container-Image. Das Image wird mit unveränderlichem Digest registriert. Ein separater Pull Request aktualisiert den GitOps-Stand; Argo CD synchronisiert erst nach Review.

Auslöser und erwartetes Ergebnis bestimmen.
Verantwortliche Komponente und Datenverantwortung benennen.
Fehlerpfade und Wiederholbarkeit festlegen.
Messsignale und Betriebshandlung definieren.

4. Code oder KonfigurationCode

jobs:
  verify:
    steps:
      - run: ./mvnw verify
      - run: ./mvnw cyclonedx:makeAggregateBom
      - run: docker build --pull --tag registry/order:${GIT_SHA} .
      # Nur bauen und registrieren. Produktivfreigabe erfolgt separat über GitOps.

Was passiert hier? Das Beispiel zeigt die kleinstmögliche Form der Entscheidung. Werte, Identitäten und Ressourcen müssen an die eigene Umgebung angepasst werden. Es wird in der Academy nichts automatisch ausgeführt.

5. Warum so – und warum nicht anders?Entscheidung

Für kleine Teams kann eine einfache CI-Pipeline mit manuellem Deployment genügen. GitOps lohnt sich, wenn Nachvollziehbarkeit, mehrere Umgebungen und kontrollierte Änderungen wichtiger werden.

Frage	Prüfung
Nutzen	Welches messbare Problem verschwindet?
Komplexität	Welche neuen Betriebs- und Lernkosten entstehen?
Alternative	Welche einfachere Lösung wäre ausreichend?
Exit	Wie kann die Entscheidung später geändert werden?

6. Sicherheit und DatenschutzSecurity

Verwende minimale Rechte, kurze Gültigkeiten, nachvollziehbare Identitäten und verschlüsselte Transportwege. Geheimnisse gehören nicht in Quellcode, Images oder öffentliche Logs. Prüfe außerdem, welche personenbezogenen Daten wirklich benötigt und wie lange sie gespeichert werden.

Warnung: Technisch erfolgreiche Verarbeitung kann fachlich oder datenschutzrechtlich trotzdem falsch sein.

7. Performance und SkalierungPerformance

Optimiere erst nach Messung. Definiere Durchsatz, Latenz, Parallelität und Error Budget (Error Budget). Prüfe anschließend, ob Engpass, Warteschlange oder Abhängigkeit das Ziel begrenzt. Lokale Beschleunigung kann das Gesamtsystem verschlechtern, wenn sie mehr Last auf nachgelagerte Komponenten verlagert.

8. Typische FehlerTroubleshooting

Komponente wird eingeführt, ohne das gelöste Problem zu benennen.
Nur der Happy Path ist beschrieben; Wiederholung und Teilfehler fehlen.
Monitoring misst Technik, aber nicht den betroffenen Geschäftsprozess.
Ein Sicherheitsmechanismus ist vorhanden, aber Rollen und Verantwortlichkeiten sind unklar.

9. DiagnosewegBetrieb

Symptom in Benutzerwirkung übersetzen.
Zeitpunkt, Umfang und letzte Änderung feststellen.
Trace oder Correlation-ID durch den Ablauf verfolgen.
Metriken, Logs und Datenzustand gegeneinander prüfen.
Nur reversible Maßnahmen durchführen und Wirkung messen.

10. LernkontrolleSelbsttest

Erkläre ohne Fachbegriffe: Welches Problem löst dieser Knoten für CommerceOne?

Entscheide: Wann wäre die einfachere Alternative besser?

Diagnostiziere: Welches erste Signal würdest du bei einem Fehler prüfen und warum?

Eigene Notiz

Delivery: vollständiger Zusammenhang

CI/CD und GitOps verbinden Quellcode mit einer nachvollziehbaren produktiven Version. Die Pipeline prüft und baut ein unveränderliches Artefakt. GitOps beschreibt anschließend den gewünschten Laufzeitstand in Git; Argo CD gleicht diesen Zustand mit Kubernetes ab.

Wie funktioniert der Ablauf?Funktionsweise

Ein Commit löst Tests, statische Analyse, Dependency- und Secret-Scan, SBOM-Erzeugung sowie Container-Build aus. Das Image erhält einen unveränderlichen Digest. Eine getrennte Änderung aktualisiert den Digest im Deployment-Repository. Argo CD zeigt Drift und synchronisiert kontrolliert.

Konkretes CommerceOne-BeispielPraxis

CommerceOne veröffentlicht `order-service@sha256:...`. Die Freigabe ändert nur den Digest im Helm-Values-File. Ein Rollback stellt den vorherigen Git-Stand wieder her. Dadurch ist nachvollziehbar, welche Version wann, warum und durch wen ausgerollt wurde.

- name: Build and verify
  run: ./mvnw verify
- name: Generate SBOM
  run: ./mvnw cyclonedx:makeAggregateBom
- name: Build image
  run: docker build -t order-service:${GITHUB_SHA} .

So liest du das Beispiel: Identitäten und Zustände werden ausdrücklich benannt. Wiederholung, Teilfehler und Beobachtbarkeit sind Teil des Designs. Das Beispiel ist zum Lesen und Anpassen gedacht; es wird nichts automatisch ausgeführt.

Entscheidungs- und DiagnosefragenReflexion

Welches fachliche Ergebnis soll für den Benutzer entstehen?
Welche Komponente besitzt die Verantwortung und welche Daten gehören ihr?
Was passiert bei Timeout, Wiederholung oder Teilausfall?
Welches Signal beweist, dass der Ablauf korrekt funktioniert?
Welche einfachere Alternative wäre ausreichend?

Zusammenfassung: Eine gute Delivery-Kette trennt Build und Deployment, verwendet unveränderliche Artefakte und macht Qualität, Freigabe und Rollback überprüfbar.

← Wissensnetz Im Lernmodus weiter