CI/CD-Pipeline · Mindmaps

CI/CD-Pipeline · Mindmaps

Die interaktive MindMap-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 Mindmap

• Beginnen Sie beim Thema in der Mitte und folgen Sie einem farbigen Zweig zu den zugehörigen Ideen.
• Geschwungene Linien zeigen Beziehungen; Pfeile stehen nur dort, wo die Richtung wichtig ist.

Commit & build

Dieser Zweig verbindet “Developer commits code”, “CI server builds the application”.

Verify

Dieser Zweig verbindet “Unit and integration tests run”, “The gate is what makes it CI: a commit that fails a test or a security scan never reaches the registry, let alone production.”, “Build failed — fix and recommit”.

Package

Dieser Zweig verbindet “Package the artifact and push to the registry”.

Release

Dieser Zweig verbindet “Deploy to staging and run smoke tests”, “Deploy to production”.

Observe & recover

Dieser Zweig verbindet “Deployment is not the end of the pipeline: error rates, latency and availability metrics decide whether the release stays.”, “Release is live and monitored”, “Roll back to the last good version”.

Verbindungen zwischen den Zweigen

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.

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. Mittleres Thema anpassen

   Benennen Sie das Thema für Ihr Projekt oder Ihren Unterricht um.

2. Zweige ausbauen

   Bearbeiten Sie Ideen und ergänzen Sie Beispiele oder Notizen.

3. Ideen verbinden

   Zeichnen Sie Verbindungen zwischen Zweigen; Pfeile zeigen eine wichtige Richtung an.

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 Mindmap in QueryChart bearbeiten

Öffnen Sie die Mindmap auf einer bearbeitbaren Leinwand. Verschieben Sie Ideen und ergänzen Sie Zweige und Verbindungen.

Diese Mindmap in QueryChart bearbeiten