Welche Vor-Deployment-Prüfungen haben im letzten Jahr tatsächlich ein schlechtes Release gestoppt, und welche haben nie ausgelöst?

Offene Frage

Eine Release-Pipeline sammelt im Lauf der Zeit Schranken an: Unit- und Integrationstests, eine Build-Reproduzierbarkeitsprüfung, einen Container-Scan, einen Smoke-Test nach dem Deployment, einen Canary-Vergleich, eine manuelle Freigabe und eine Rollout-Frist. Die Kubernetes-Dokumentation zu Deployments beschreibt beispielsweise progressDeadlineSeconds und hält fest, dass Kubernetes bei einem ins Stocken geratenen Deployment keine andere Massnahme ergreift, als eine Bedingung ProgressDeadlineExceeded zu melden; etwas anderes muss darauf reagieren. Jede Schranke kostet bei jedem Release Zeit und blockiert gelegentlich ein gutes. Was dem Wiki fehlt, ist Evidenz darüber, welche Schranken sich ihren Platz verdient haben: Welche Schranken haben über ein Jahr Releases hinweg ein Release gestoppt, das einen Vorfall verursacht hätte, welche haben überhaupt nie ausgelöst, und welche haben nur bei Falsch-positiven ausgelöst, die übersteuert wurden? Führen Teams eine Aufzeichnung, die es ihnen erlaubt, dies zu beantworten, oder ist die Erinnerung an "diese Prüfung hat uns einmal gerettet" die einzige Evidenz? Und fällt die Antwort unterschiedlich aus für Schranken, die vor dem Bauen des Artefakts laufen, Schranken, die in einer Staging-Umgebung laufen, und Schranken, die den Produktions-Rollout beobachten?

Die Frage ist nicht, ob Schranken grundsätzlich gut sind, sondern welche davon für eine bestimmte Art von Dienst eine nachweisliche Erfolgsbilanz haben, damit ein Team seine Pipeline-Zeit dort investieren kann, wo sie tatsächlich etwas gestoppt hat.

Was eine nützliche Antwort enthält

Den Diensttyp, die Release-Häufigkeit und den Rollout-Mechanismus. Die Liste der Schranken, mit pro Schranke: der Anzahl Releases im Zeitraum, der Anzahl Blockierungen, wie viele Blockierungen sich im Nachhinein als echt positiv erwiesen, und wie viele übersteuert wurden. Für jeden echten Treffer, was sonst die Nutzenden erreicht hätte und wie die Schranke es bemerkte. Für Schranken, die nie ausgelöst haben, ob das Team sie entfernt hat, sie als Versicherung behielt, oder feststellte, dass sie falsch konfiguriert waren (eine Prüfung, die gar nicht scheitern konnte). Wie die Aufzeichnung geführt wurde: Pipeline-Logs, ein Feld in der Vorfallsanalyse, oder Rekonstruktion aus dem Gedächtnis, da dies bestimmt, wie sehr den Zahlen zu trauen ist. Ob der Schwellenwert einer Schranke im Zeitraum angepasst wurde, und ob eine auslösende Schranke tatsächlich eine war, die nach einem Vorfall hinzugefügt worden war. Berichte über Schranken, die monatelang unbemerkt defekt waren, sind ebenso wertvoll wie Berichte über funktionierende Schranken.