Eine Taiga-Lieferung anhand von Nachweisen prüfen

Beginnen Sie mit dem Ergebnis der Initiative

Der fiktive Ausstattungsdienst erlaubt Mitarbeitern nun, ihre eigenen Anfragen zu sehen. Beginnen Sie das Review mit Ergebnis und Umfang der Initiative. Bestimmen Sie, was gelten muss und was die Änderung erhalten muss.

Bei dieser Lieferung darf ein Mitarbeiter keine Anfrage eines anderen Mitarbeiters lesen. Führungskräfte müssen ihren definierten Zugriff behalten. Ein Test, der nur die Seite öffnet, belegt keine der beiden Bedingungen.

Verbinden Sie die Aufzeichnungen

Die Seite Runs erfasst Versuche einschließlich Fehlschlägen. Jeder Lauf benennt den ausgeführten Plan. Eine Laufseite dient der Prüfung. Entscheidungen, die die Arbeit verändern, gehören zur Initiative.

Lesen Sie die Nachweise der Schritte für Tests und Formatierung. Taiga macht fehlgeschlagene oder nicht ausgeführte Prüfungen sichtbar. Machen Sie in Ihrer Review-Zusammenfassung aus „nicht ausgeführt“ kein „bestanden“.

Prüfen Sie Annahmen und Grenzen

Suchen Sie nach Annahmen über Zugriffsmodell, Schema, Umgebung und externe Dienste. Vergleichen Sie sie mit der veröffentlichten Zielbeschreibung und dem tatsächlichen Code.

Prüfen Sie beim Ausstattungsdienst, wo die Eigentümerschaft einer Anfrage kontrolliert wird. Testen Sie eine autorisierte Anfrage, eine Anfrage eines anderen Mitarbeiters und eine nicht vorhandene Anfrage. Prüfen Sie, dass Logs keine vertraulichen Anfrageinhalte offenlegen.

Prüfen Sie auch Teständerungen. Ein bestandenes Ergebnis hat begrenzten Wert, wenn die Änderung die Assertion entfernt hat, die den Defekt erkennen würde. Nehmen Sie Änderungen an Workflow und Testkonfiguration in den Review-Umfang auf.

Geben Sie umsetzbares Feedback

Benennen Sie Verhalten, erwartetes Ergebnis und benötigte Nachweise. Zum Beispiel: „Der Endpunkt prüft die Anmeldung, aber nicht, wem die Anfrage gehört. Ergänzen Sie die serverseitige Zugriffsprüfung und einen Test mit der Anfrage eines anderen Mitarbeiters.“

Taiga kann auf Pull-Request-Review-Feedback und fehlgeschlagene Prüfungen mit Änderungen auf demselben Branch reagieren. Prüfen Sie nach Updates den neuen Commit und seine Prüfungen. Frühere Nachweise decken ein geändertes Artefakt möglicherweise nicht ab.

Wenn der Lauf wegen eines unvollständigen Plans oder einer abgeschwächten Prüfung stoppte, lesen Sie die Begründung. Entfernen Sie den Entwurfsstatus nicht allein deshalb, weil die sichtbare Prüfungsübersicht grün ist.

Treffen Sie die passende Abnahmeentscheidung

Halten Sie fest, welche Kriterien geprüft und welche noch offen sind. Lassen Sie die erforderlichen Repository-Reviews und Prüfungen die Merge-Grenze durchsetzen. Erhalten Sie jede getrennte Release-Entscheidung.

Taiga beobachtet Deployments, die Ihre Pipeline ausführt. Prüfen Sie Umgebung und Artefakt, bevor Sie Nutzern die Verfügbarkeit der Änderung mitteilen. Nach einem fehlgeschlagenen Deployment kann weiterhin die vorherige erfolgreiche Version den Traffic bedienen.

Schließen Sie das Ergebnis mit einer Prüfung auf Dienstebene ab: Der Mitarbeiter kann die Funktion nutzen, unberechtigter Zugriff wird verweigert und die betriebsverantwortliche Person kann Fehler beobachten. Fahren Sie mit dem Umgang mit einer Unterbrechung fort.