Vorlage für ein Flussdiagramm zur CI/CD-Pipeline

Eine Pipeline funktioniert am besten als Entscheidungsablauf, denn spannend ist, was einen Commit aufhält, nicht die Abfolge der Jobs, die ihn verarbeiten. Wir empfehlen folgendes Vorgehen:

1. Listen Sie alle Ergebnisse auf, die ein Commit erreichen kann: Produktion, blockierter Merge, Rollback.
2. Notieren Sie die Prüfpunkte, die diese Ergebnisse trennen, und markieren Sie, welche automatisiert sind und welche eine Person brauchen.
3. Machen Sie aus jedem Prüfpunkt einen Entscheidungsknoten mit beiden Ausgängen, einschließlich der Fehlerpfade.
4. Prüfen Sie, ob jeder Pfad ein Ende hat. Ein Pipeline-Diagramm mit einem offenen Zweig ist der Ort, an dem ein fehlgeschlagenes Deployment unbemerkt bleibt.
5. Zeichnen Sie es in dem Tool, das Ihr Publikum ohnehin nutzt. Eine kostenlose Vorlage nimmt Ihnen den Großteil der Layoutarbeit ab.

Continuous Delivery bedeutet, dass jeder erfolgreiche Build releasebereit ist, eine Person aber entscheidet, wann. Continuous Deployment bedeutet, dass jeder erfolgreiche Build automatisch in die Produktion geht, ohne menschlichen Eingriff.

Der Freigabe-Prüfpunkt in diesem Diagramm ist der gesamte Unterschied. Entfernen Sie ihn, und dieselbe Pipeline wird zu Continuous Deployment. Hier lohnt sich eine bewusste Entscheidung: Teams sprechen oft von Deployment, betreiben aber Delivery und bemerken die Lücke erst bei einem Audit.

Continuous Integration umfasst alles bis zum Test-Prüfpunkt: Code häufig zusammenführen und automatisch nachweisen, dass er baut und die Tests besteht. Continuous Delivery oder Deployment umfasst alles danach, also den geprüften Build ins Staging und dann in die Produktion zu bringen.

In diesem Diagramm endet CI bei der Entscheidung Tests bestanden, und CD beginnt beim Deployment ins Staging. Die Trennung ist nicht akademisch: Beide scheitern meist aus unterschiedlichen Gründen und werden oft von unterschiedlichen Personen verantwortet.

Jeder davon hält einen Commit aus einem anderen Grund auf:

• Tests bestanden: automatisiert, objektiv und schnell. Ein Nein benachrichtigt den Autor und blockiert den Merge.
• Freigabe: manuell, ermessensbasiert und langsamer. Ein Nein führt zu Rollback und Stopp, statt es erneut zu versuchen.

Fügen Sie bei Bedarf einen weiteren Prüfpunkt für Security-Scans, Performance-Budgets oder ein Change-Advisory-Review hinzu; die Verzweigungen bleiben verbunden, während sich das Diagramm neu anordnet.

Build und Tests ausführen verwendet statt eines einfachen Rechtecks die Form für einen vordefinierten Prozess. In der Flussdiagramm-Notation kennzeichnet sie einen Schritt, der an anderer Stelle im Detail definiert ist, in diesem Fall in der Job-Konfiguration Ihres CI-Systems.

Auf einer Folie ist das ein nützliches Signal. Es zeigt dem Leser, dass das Kästchen eine Pipeline zusammenfasst, die er nachlesen kann, statt einer einzelnen Aktion, ohne das Diagramm mit jeder Testphase zu überladen.

Der Commit führt zu Benachrichtigen und Merge blockieren. Beide Hälften sind wichtig: Benachrichtigen ohne Blockieren heißt, dass der Fehler ignoriert wird, und Blockieren ohne Benachrichtigen heißt, dass der Autor es von jemand anderem erfährt.

Dass dies als Endergebnis und nicht als Schleife zurück dargestellt ist, ist beabsichtigt. Ein fehlgeschlagener Build wird von der Pipeline nicht erneut versucht, sondern geht an die Person zurück, die den Code geschrieben hat. So bleibt die Korrektur bei der Person mit dem nötigen Kontext.

Das hängt davon ab, wovor Sie sich schützen wollen. Ein manueller Prüfpunkt erkennt, was die Automatisierung nicht beurteilen kann: ein riskantes Release vor einem langen Wochenende, eine Änderung, über die Kunden vorab informiert werden müssen, eine Compliance-Anforderung an die Funktionstrennung. Er kostet aber Geschwindigkeit und wird zum reinen Abnicken, wenn nie jemand Nein sagt.

Ein sinnvoller Test: Wenn Ihre freigebende Person in sechs Monaten nichts abgelehnt hat, ist der Prüfpunkt nur Theater. Dann sollten Sie ihn entweder automatisieren oder die Kriterien ergänzen, die eine Ablehnung überhaupt möglich machen.

Jeder Prüfpunkt sollte eine benannte verantwortliche Stelle haben, und das ist selten dasselbe Team:

• Entwicklung: der Commit und die Behebung von allem, was der Test-Prüfpunkt blockiert.
• Plattform oder DevOps: die Build-Konfiguration, die Staging-Umgebung und der Rollback-Mechanismus.
• Release Manager oder Tech Lead: die Freigabeentscheidung selbst.
• Security oder Compliance: die Kriterien, gegen die der Prüfpunkt prüft, sofern es welche gibt.

Wenn dieselbe Person den Code schreibt und das Release freigibt, bietet der Prüfpunkt nicht die Trennung, die er zu bieten scheint.

PowerPoint kann das mit SmartArt und der Shapes gallery, aber die Arbeit ist manuell: Sie platzieren jede Raute selbst, beschriften beide Ausgänge und verbinden die Verbinder neu, sobald sich etwas verschiebt. Bei einer Pipeline mit zwei Prüfpunkten und drei Endergebnissen ist genau das der Grund, warum das Diagramm irgendwann nicht mehr aktualisiert wird.

Schneller geht es mit dem Lucen Flowchart tab: Er rastet Verbinder an den Ankerpunkten der Formen ein und ordnet das Diagramm mit Auto Layout neu an, wenn Sie einen Prüfpunkt ergänzen. In beiden Fällen bleibt das Ergebnis eine Gruppe nativer PowerPoint-Objekte auf Ihrer Folie.

Der Download ist eine kostenlose .pptx-Datei aus nativen PowerPoint-Formen. Jede Person kann sie öffnen, lesen und bearbeiten, und Sie können sie wie jede andere Präsentation teilen; Empfänger müssen nichts installieren.

Die intelligenten Verbinder, Auto Layout und Lucen AI stammen aus dem Lucen Flowchart Add-in. Es ergänzt das Menüband um einen Lucen Flowchart tab und läuft unter Windows mit PowerPoint 2016 oder neuer sowie mit PowerPoint für Microsoft 365. PowerPoint für das Web, Mac und mobile Geräte werden nicht unterstützt. Anleitungen zur Einrichtung und Fehlerbehebung finden Sie im Lucen Support.