CI/CD-Pipeline — vom Commit in den Produktivbetrieb

CI/CD-Pipeline — vom Commit in den Produktivbetrieb

Die interaktive FlowJam-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.

So lesen Sie diese Darstellung

• Lesen Sie die fünf Spalten von links nach rechts: Commit, Bauen und testen, Verpacken, Ausrollen, Überwachen.
• Verfolgen Sie die Änderung über die Bahnen: Sie verlässt den Entwickler, wird vom CI-Server verarbeitet, liegt in der Registry und läuft auf dem Deployment-Ziel.
• Die beiden Entscheidungen sind Freigabestufen — ein „Nein“ an einer von beiden schickt die Änderung an einen ausdrücklichen Fehlerendpunkt statt weiter.

Bauen und testen

„Entwickler committet Code“ startet den Ablauf, und „CI-Server baut die Anwendung“ sowie „Unit- und Integrationstests laufen“ sind die Aufgabe der Continuous Integration: Jeder Commit wird für sich kompiliert und getestet. „Alle Prüfungen bestanden?“ ist die Freigabestufe, die der CI ihren Namen gibt — ein fehlgeschlagener Commit wird bei „Build fehlgeschlagen — beheben und neu committen“ abgewiesen, bevor er den Strom der Artefakte verunreinigen kann.

Verpacken und ausrollen

„Artefakt verpacken und in die Registry laden“ erzeugt den unveränderlichen, versionierten Build — genau das, was später läuft. „In die Staging-Umgebung ausrollen und Smoke-Tests ausführen“ weist ihn in einer produktionsnahen Umgebung nach, dann liefert „In den Produktivbetrieb ausrollen“ ihn aus. Die Bahn der Registry ist die Übergabe: Das Artefakt wird einmal gebaut und von jeder späteren Stufe genutzt, und genau das macht die ausgerollte Version identisch mit der getesteten.

Die Freigabestufe der Überwachung

„Nach dem Ausrollen gesund?“ ist die letzte Entscheidung: Metriken, Logs und Alarmierung nach dem Release entscheiden, ob „Release ist live und wird überwacht“ gilt oder „Auf die letzte funktionierende Version zurücksetzen“. Das Rollback ist als echter Schritt gezeichnet, der in den gesunden Endzustand zurückführt, denn erst ein automatisiertes Rollback macht schnelles Ausrollen sicher.

Wichtige Zusammenhänge und Erkenntnisse

• CI ist die Freigabestufe, bevor irgendetwas ausgeliefert wird: jeden Commit bauen und testen und Fehler an der Quelle abweisen.
• Das Artefakt in der Registry wird einmal gebaut und überall ausgeführt — davon hängt die Reproduzierbarkeit des Deployments ab.
• Die Staging-Umgebung weist das Artefakt in einer produktionsnahen Umgebung nach, bevor der Produktivbetrieb es sieht.
• Der Zustand nach dem Ausrollen ist die eigentliche Freigabestufe — die Überwachung entscheidet, ob ein Release bleibt, nicht das Deployment-Skript.
• Eine Pipeline ohne Rollback lässt sich nicht sicher automatisieren; die Zeichenfläche zeichnet das Rollback als gleichwertigen Pfad.

Wann Sie diese Darstellung nutzen

• Einem Team den Unterschied zwischen Continuous Integration und Continuous Delivery beibringen, bevor es eine Pipeline baut.
• Eine Pipeline entwerfen: Die beiden Freigabestufen sagen, wo die Automatisierung aufhören und das Urteil (oder das Rollback) beginnen muss.
• Eine bestehende Pipeline prüfen — eine fehlende Freigabestufe für den Zustand ist ein Release, das ohne Entscheidung läuft.

So funktioniert es

1. Bilden Sie Ihre tatsächlichen Pipeline-Stufen ab

   Ersetzen Sie die allgemeinen Stufen durch die, die Ihre CI ausführt — Lint, Container-Build, Migration, Canary —, und behalten Sie eine Freigabestufe, bevor etwas ausgeliefert wird.

2. Benennen Sie Ihre Prüfungen

   Vermerken Sie am Test-Kasten die tatsächlichen Suiten und Sicherheitsscans, die Sie ausführen, und was die Freigabestufe „Alle Prüfungen bestanden?“ über Unit-Tests hinaus verlangt.

3. Ergänzen Sie den Canary-Zweig

   Fügen Sie zwischen Staging-Umgebung und Produktivbetrieb einen Canary-Schritt ein — leiten Sie einen kleinen Anteil des Datenverkehrs auf die neue Version und beobachten Sie die Freigabestufe für den Zustand, bevor Sie vollständig ausrollen.

4. Legen Sie das Rollback fest

   Vermerken Sie am Rollback-Kasten, was es in Ihrem System tatsächlich tut — das vorherige Image erneut ausrollen, eine Datenbanksicherung einspielen — und wer oder was es auslöst.

Häufig gestellte Fragen

Worin unterscheiden sich CI und CD?

Continuous Integration (CI) ist die Praxis, jeden Commit automatisch zu bauen und zu testen, sodass Probleme in dem Moment auffallen, in dem sie entstehen, und nicht erst beim Release. Continuous Delivery (CD) nimmt das Ergebnis der CI und automatisiert dessen Weg bis zum Deployment — Verpacken, Staging, Ausliefern —, mit Freigabestufen, die entscheiden, wann es sicher ist. CI ist die erste Freigabestufe der Pipeline, CD ist alles danach.

Warum sind Freigabestufen in einer CI/CD-Pipeline wichtig?

Weil die Automatisierung die menschlichen Prüfpunkte entfernt, die früher Probleme aufgefangen haben. Die Freigabestufen der Pipeline ersetzen sie durch Entscheidungen: Die Freigabestufe der Tests stoppt einen fehlgeschlagenen Build, bevor er ausgeliefert wird, und die des Zustands stoppt ein schlechtes Release, nachdem es ausgeliefert wurde. Genau deshalb zeichnet die Darstellung beide als Entscheidungen — eine Pipeline ist nur so vertrauenswürdig wie ihre Freigabestufen.

Was ist ein Rollback, und warum braucht die Pipeline eines?

Ein Rollback ist die Rückkehr des Systems zur letzten als funktionierend bekannten Version, wenn ein Release nach dem Ausrollen scheitert. Pipelines brauchen es, weil Zustandsprüfungen unvollkommen sind und sich der Produktivbetrieb auf eine Weise danebenbenehmen kann, die die Staging-Umgebung nie gezeigt hat. Ein automatisiertes Rollback ist es, was Teams häufiges Ausrollen erlaubt — die Kosten eines schlechten Release sind dann eine Rücknahme und kein Vorfall.

Wie fügt sich die Artefakt-Registry ein?

In der Registry liegt das gebaute Artefakt der Pipeline mit einer Version. Jede spätere Stufe — Staging, Produktivbetrieb, Rollback — rollt genau das Artefakt aus der Registry aus, nie einen neuen Build. Das macht den ausgerollten Code identisch mit dem getesteten, und es macht auch das Rollback sicher: Die letzte funktionierende Version liegt weiterhin in der Registry.

Diese Darstellung in QueryChart (FlowJam) bearbeiten

Öffnen Sie genau diese CI/CD-Zeichenfläche als eigenes Diagramm, benennen Sie die Stufen auf Ihre Pipeline um, und ergänzen Sie Ihre echten Freigabestufen.

Diese Darstellung in QueryChart (FlowJam) bearbeiten