So finden Sie Engpässe im Software-Release-Prozess
Zeichnen Sie den Release-Prozess als Flussdiagramm, zählen Sie, was jede Entscheidung verlässt, und zeigen Sie die Zahlen als Sankey-Diagramm. Finden Sie das Gate, an dem Builds scheitern oder warten.
Ein Release-Engpass ist das Gate, an dem sich Arbeit staut, scheitert oder zurückkommt. Diese Anleitung zeichnet zuerst den Prozess, sodass jedes Gate eine Entscheidung mit benannten Ausgängen ist, und zählt dann die Releases an diesen Ausgängen.
Kurz gesagt
- Zeichnen Sie den Prozess als Entscheidungen mit beschrifteten Ausgängen, bevor Sie etwas zählen.
- Zählen Sie Releases (oder Builds) an jedem Ausgang für einen Zeitraum.
- Ein gewichtiger Rückführungszweig an einem Gate ist ein Engpass, auch wenn das Gate schnell ist.
- Zeigen Sie die Zahlen als Sankey-Diagramm und erklären Sie sie mit dem Flussdiagramm.
Beginnen Sie mit den Gates, nicht mit den Zahlen
Teams suchen den langsamen Schritt meist über durchschnittliche Dauern. Das findet langsame Aufgaben, aber nicht die Gates, die Arbeit zurückschicken. Ein Release kann einen Tag im Test verbringen und trotzdem eine Woche verlieren, weil ein fehlgeschlagener Test es zu einem Behebungsschritt zurückführt und der Zyklus von vorn läuft. Sichtbar wird das, wenn Sie den Prozess mit seinen Entscheidungen zeichnen und zählen, wie viele Releases jeden Ausgang nehmen.
Das Flussdiagramm liefert die Struktur: Jede Entscheidung hat beschriftete Zweige, und jeder Zweig hat eine Zahl. Das Beispiel ist ein Release-Prozess mit vier Entscheidungen: automatisierte Tests, Go oder No-Go, Zustand in der Produktion und Fehler in der Produktion. Sobald Sie Zahlen je Zweig haben, zeigt ein Sankey-Diagramm sie als Breiten. Die Build-Stufe zeigt /de/sankey/ci-pipeline-outcomes, die davorliegende Review-Stufe /de/sankey/pull-request-review-flow.
Bleiben Sie bei den Aussagen zurückhaltend. Zahlen zeigen, wo Arbeit ein Gate verlässt, nicht warum. Den Grund finden Sie, indem Sie die gescheiterten Items lesen und mit den Menschen sprechen, die das Gate betreiben.
Ein Release-Prozess, in Etappen aufgebaut
Zwanzig Schritte und vier Entscheidungen. Jede Entscheidung ist eine Stelle, an der ein Sankey-Diagramm Arbeit in zwei Richtungen abfließen zeigt.
Build und automatisierte Tests
Der Prozess beginnt mit „Code für das Release fertiggestellt“, friert den Umfang ein und fährt die automatisierten Tests. Die erste Entscheidung, „Automatisierte Tests bestanden?“, hat einen Zweig „Fehlgeschlagen“, der über „Fehler im Release-Branch beheben“ zum Build zurückführt. Diese Schleife ist die erste Stelle zum Zählen.
Staging, Abnahme und die Go-Entscheidung
Ein Build, der besteht, geht auf Staging, in Regression und UAT, und das Freigabedokument wird zusammengestellt und genehmigt. „Go oder No-Go?“ hat einen Zweig „No-Go“, der zum Behebungsschritt zurückführt, sodass ein Release spät im Prozess zurückkommen kann.
Produktion und der Weg zurück
Das Release wird im Fenster deployt und per Smoke-Test geprüft. „Release stabil?“ teilt sich in die Überwachung oder in ein Rollback, das zum Behebungsschritt zurückführt. Ein Rollback ist der teuerste Ausgang, seine Zahl ist daher am wichtigsten.
Überwachung und Hotfix
Nach der Beobachtungszeit schickt „Fehler in der Produktion gefunden?“ das Release zu einem Hotfix, der beim Deployment wieder einsteigt, oder zu Release Notes und Abschluss. Zählen Sie, wie oft der Hotfix-Zweig genommen wird.
So funktioniert es
Den Prozess mit seinen Entscheidungen zeichnen
Nehmen Sie jedes Gate als Entscheidung mit beschrifteten Ausgängen auf, etwa „Bestanden“ und „Fehlgeschlagen“. Ein Gate als einfacher Schritt verbirgt den Ausgang, den Sie zählen wollen.
Zeitraum und Einheit wählen
Nehmen Sie das letzte Quartal und zählen Sie Releases, oder Builds, wenn Sie oft releasen. Sagen Sie in der Datenanmerkung, was.
Zählen, was jede Entscheidung verlässt
Zählen Sie für jede Entscheidung, wie viele Items welchen Ausgang nahmen. Die Zahlen stammen aus CI-System, Tickets oder Release-Log.
Die Zahlen als Sankey-Diagramm zeichnen
Nutzen Sie die Entscheidungen als Knoten und die Ausgänge als Flüsse. Prüfen Sie, dass in jeden Knoten so viel hineinfließt, wie ihn verlässt.
Zuerst den breitesten Rückführungszweig lesen
Der breiteste Zweig, der rückwärts zeigt, ist der wahrscheinliche Engpass. Lesen Sie diese Items, um den Grund zu finden.
Häufige Fehler
Nur das Endergebnis zählen
Wenn Sie nur zählen, was geliefert wurde, verschwinden die Schleifen. Zählen Sie an jeder Entscheidung, sonst zeigt das Sankey-Diagramm einen glatten Prozess, den es nicht gab.
Einheiten mischen
Builds, Releases und Tickets sind verschiedene Einheiten. Wählen Sie eine für das ganze Diagramm und sagen Sie es.
Zählwerte als Ursachen lesen
Ein breiter Zweig „Fehlgeschlagen“ sagt, dass Tests oft scheitern, nicht warum. Sehen Sie sich die gescheiterten Items an, bevor Sie den Prozess ändern.
Das Software-Release-Flussdiagramm öffnen
Öffnen Sie die Release-Vorlage, passen Sie die Gates an Ihre an und zählen Sie die Ausgänge.
Verwandte Anleitungen
Häufig gestellte Fragen
Warum ein Flussdiagramm zeichnen, wenn ich nur ein Sankey-Diagramm will?
Weil das Flussdiagramm festlegt, was die Knoten sind. Ohne es zeigt das Sankey-Diagramm die Stufen, die Ihr Tool zufällig exportiert, und die sind oft nicht die Gates, an denen Menschen entscheiden.
Wie viele Releases brauche ich?
Genug, dass jeder Ausgang mehr als eine Handvoll Items hat. Bei weniger als etwa 20 zeigen Sie die Zahlen besser in einer Tabelle als in einem Diagramm.
Ersetzt das die Messung der Durchlaufzeit?
Nein. Die Durchlaufzeit sagt, wie lange; das Sankey-Diagramm sagt, wo Arbeit abgeht oder zurückkommt. Nutzen Sie beides und vergleichen Sie denselben Zeitraum.