Nach dem Merge | kanman Dokumentation

Ein gemergter Pull Request ist nicht das Ende einer Story. kanman bleibt an seiner Arbeit dran, bis sie in Produktion ist, und sagt allen Bescheid, die darauf warten, so wie ein guter Kollege den Kreis schließt.

Richten Sie das in der Karte Nach dem Merge unter Team > Prüfungen und Auslieferung ein (/<workspace>/teams/<team>/team/checks). Alte Links auf die frühere Seite Nach dem Merge führen zu dieser Karte. Jede Änderung wird sofort gespeichert: Daneben erscheint kurz Gespeichert, und Rückgängig holt den vorherigen Wert zurück.

Versionshinweise

Direkt nach dem Merge schreibt kanman den Versionshinweis der Story dorthin, wo Ihr Team ihn haben möchte:

Einstellung	Was kanman tut
In der Beschreibung des Pull- oder Merge-Requests (Standard)	Ergänzt den gemergten Pull- oder Merge-Request um einen Abschnitt Versionshinweise: Story-Schlüssel, Titel und Akzeptanzkriterien.
In der Changelog-Datei	Schlägt den Eintrag in einem kleinen Folge-Pull- oder Merge-Request vor, der nur den Changelog ändert (`CHANGELOG.md`, wenn Sie keine andere Datei nennen). kanman folgt dem Format der Datei: In einer Keep a Changelog-Datei kommt der Eintrag unter Unreleased, in Fixed, Added oder Changed. Ohne Changelog legt kanman einen an. Sie prüfen und mergen den Folge-Request wie jede andere Änderung.
Aus	Keine Versionshinweise.

kanman kommentiert außerdem im Tracker-Issue, dass die Story gemergt ist und dass es das Deployment beobachtet.

Das Deployment beobachten

kanman beobachtet die Deployments des Repositorys der Story:

GitHub: Deployments und ihr Status, wie GitHub sie meldet.
GitLab: Umgebungen und Deployments, auch bei einem GitLab hinter einem VPN, das kanman alle paar Minuten über Ihren Runner liest.

Ein erfolgreiches Deployment in eine der Produktionsumgebungen des Teams liefert jede Story des Repositorys aus, die vorher gemergt wurde. Fügen Sie die Umgebungen als Chips hinzu; prod* passt auf jede Umgebung, die mit prod beginnt. Standard sind production, prod und live.

Produktion prüfen

kanman nennt eine Story erst live, wenn es gesehen hat, dass sie dort funktioniert:

Die Abnahmeprüfung: Hat die Story eine Live-Abnahmeprüfung (eine UI- oder API-Prüfung in ihrem Demonstrate-Block), führt kanman sie gegen die ausgerollte Umgebung aus.
Ihre Signale: Ist seit dem Merge ein Incident des Teams aufgegangen und noch offen, sagt kanman das, statt die Story live zu nennen. Siehe Incidents und Rufbereitschaft.

Was kanman gesehen hat	Was es sagt
Prüfung in Produktion bestanden, kein Incident offen	Live auf production
Prüfung schlägt in Produktion fehl	Fehlschlag auf production, mit dem Ergebnis. kanman legt sofort eine Regressions-Story an.
Seit dem Merge ist ein Incident aufgegangen	Ausgerollt, Incident offen, mit dem Incident
Keine Live-Prüfung für die Story	Ausgerollt, nicht geprüft: kanman sagt klar, dass es das Verhalten nicht selbst bestätigen kann

Kann eine Prüfung nicht laufen (zum Beispiel, während Ihr Runner offline ist), wartet kanman und versucht es erneut; es rät nie.

Den Kreis schließen

Sobald kanman weiß, wie die Story in Produktion dasteht, sagt es allen einmal Bescheid:

Das Tracker-Issue bekommt einen Kommentar, zum Beispiel “PU-43 ist live auf production: Die Abnahmeprüfung ist dort bestanden”. Eine Story, die live ist, bleibt in ihrem Status Fertig.
Die Karte der Story im Chat des Teams endet mit dem Produktionsschritt, sodass alle, die der Story folgen, es ohne neue Nachricht sehen.
Dort, wo die Arbeit begann: im Slack-Thread, aus dem die Anfrage kam, oder im Pull- oder Merge-Request, in dem jemand kanman erwähnt hat.

Abschalten können Sie das mit Allen sagen, wenn es live ist; kanman hält das Ergebnis dann nur an der Story fest.