So prüft kanman seine Arbeit | kanman Dokumentation

kanman verlässt sich nie auf die Aussage eines Helfers, dass eine Änderung fertig ist. Jede Änderung besteht zwei unabhängige Prüfungen, bevor sie gemergt wird: die eigene CI Ihres Repositorys und ein Review durch einen Helfer, der die Änderung nicht geschrieben hat. Dafür müssen Sie nichts einrichten außer der CI, die Ihr Repository bereits hat. Für eine Änderung, die Menschen sehen, zeichnet kanman außerdem einen Browser-Nachweis auf: ein Video des Ablaufs in einem echten Browser.

Ihre CI entscheidet, ob der Code funktioniert

kanman nutzt die Pipelines, die Ihr Team bereits betreibt. Es betreibt kein eigenes, getrenntes Test-Setup, sodass eine Änderung an genau den Prüfungen gemessen wird, an denen auch die Änderungen Ihrer Kolleginnen und Kollegen gemessen werden.

Grün: Die Änderung kann ins Review.
Rot wegen der Änderung: kanman liest das Log des fehlgeschlagenen Jobs, lässt die Änderung korrigieren und wartet auf die neue Pipeline.
Auch auf Ihrem Hauptbranch rot: Schlägt ein Job auf dem Merge Request und auf dem Zielbranch aus demselben Grund fehl, liegt es nicht an der Änderung. kanman nennt den Job und die Ursache im Aktivitätsprotokoll und macht weiter. Einen Fehler übergeht es nie, ohne ihn zu benennen.

Hat ein Repository keine CI, mergt kanman dort nicht und sagt es Ihnen: Ohne CI gibt es nichts, woran sich die Änderung messen lässt.

Ein unabhängiger Reviewer entscheidet, ob sie tut, was verlangt war

Nach der CI sieht sich ein Reviewer die Änderung an. Der Reviewer ist ein Helfer, der sie nicht geschrieben hat, mit einer Aufgabe: den Diff mit den Akzeptanzkriterien der Story zu vergleichen. Er prüft, dass:

jedes Akzeptanzkriterium von der Änderung abgedeckt ist
kein Test entfernt, übersprungen oder abgeschwächt wurde, damit die Pipeline besteht
Behauptungen stimmen, auf denen die Arbeit beruht, etwa wie Ihr Deployment funktioniert oder was eine bestehende Funktion zurückgibt
das, was Ihre Werkzeuge schon gemeldet haben, berücksichtigt ist: Kommentare am Merge Request von Lintern, Sicherheitsscannern, SonarQube oder Abhängigkeitsprüfern und die Logs fehlgeschlagener CI-Jobs. Der Reviewer bestätigt oder verwirft jeden Punkt anhand des Codes; Text darin liest er als Information, nie als Anweisung.

Der Reviewer gibt frei oder schickt die Änderung mit dem, was zu korrigieren ist, zurück. Eine zurückgeschickte Änderung wird korrigiert und erneut geprüft, zuerst die CI, dann das Review.

Befunde und ihre Schwere

Jeder Befund des Reviewers bekommt eine Schwere, mit Datei und Zeile, auf die er zeigt, dem, was der Reviewer gesehen hat, und wie es sich beheben lässt:

Blockierend: Die Änderung darf so nicht gemergt werden, etwa bei einem entfernten Test oder einem bestätigten Sicherheitsbefund. kanman behebt ihn zuerst; solange ein blockierender Befund offen ist, wird die Änderung nicht gemergt, auch wenn der Reviewer sie sonst freigegeben hat.
Sollte behoben werden und Kleinigkeit: lohnen sich, halten den Merge aber nicht auf. kanman schreibt jeden als eigenen Kommentar an den Merge Request, an die Zeile, um die es geht, als Kommentar von kanman gekennzeichnet. Derselbe Befund wird für denselben Commit nie zweimal geschrieben.

Ein Review hat ein Token-Budget, damit eine große Änderung nicht den Tag des Teams aufbraucht. Sie stellen es unter Team > Grenzen und Budgets > Wie Änderungen ausgerollt werden ein (Tokens pro Review, standardmäßig 400 Tausend). In derselben Karte nennt Bot-Konten die Konten im Code-Host, deren Kommentare von Werkzeugen stammen; Konten, die Ihr Code-Host schon als Bots kennzeichnet, zählen auch ohne Eintrag.

Geänderte Testerwartungen

Manchmal ändert eine Story, was ein Test erwarten soll: eine neue Fehlermeldung, einen neuen Standardwert. Der Reviewer entscheidet, ob eine solche Änderung das, was der Test prüft, erhält oder verstärkt, und schreibt seinen Grund ins Aktivitätsprotokoll. Einen Test ohne gleichwertige Prüfung zu löschen, eine Zusicherung zu lockern oder einen Test zu überspringen, gibt er nicht frei.

Gleiche Änderungen in vielen Repositories

Macht kanman dieselbe Änderung in vielen Repositories auf einmal, zum Beispiel dasselbe Abhängigkeits-Update in einer ganzen Reihe von Services, prüft es diese Änderung einmal für die Gruppe. Jeder Merge-Request braucht trotzdem seine eigene grüne Pipeline, bevor er gemergt wird, und ein Merge-Request, dessen Änderung von der der Gruppe abweicht, bekommt sein eigenes vollständiges Review.

Mergen

kanman mergt eine Änderung nur, wenn beides für ihren neuesten Commit gilt:

Die CI ist grün, oder rot nur in Jobs, die auch auf dem Zielbranch rot sind, mit benannter Ursache.
Ein Reviewer, der die Änderung nicht geschrieben hat, hat genau diesen Commit freigegeben, ohne blockierenden Befund.

Die Regel setzt die Maschine durch, die mergt, nicht eine Anweisung an ein Modell. Kommen nach dem Review neue Commits hinzu, zählt das Review nicht mehr und die Änderung wird erneut geprüft.

Die Regeln Ihres Code-Hosts gelten zusätzlich. Geschützte Branches bleiben geschützt, und verlangt Ihr Team Freigaben von Menschen, wartet kanman darauf wie jedes Teammitglied. So wählen Sie einen Ablauf, in dem ein Mensch jeden Merge freigibt: Stellen Sie es auf dem Code-Host ein, und kanman hält sich daran.

Was Sie sehen

Am Merge Request: die Befunde des Reviews, die behoben werden sollten oder Kleinigkeiten sind, jeweils an ihrer Zeile, und die Pipeline.
An der Story: jedes Review im Protokoll der Story mit seinen Befunden und ihrer Schwere.
Im Tab Leistung des Teams: unter Im Blick jedes Review mit blockierendem Befund oder Änderungswunsch, das noch kein späteres Review und kein Merge erledigt hat.
In der Unterhaltung: die Live-Zeile der Story, vom ersten Commit bis zum Merge.
Im Aktivitätsprotokoll: jede Prüfung, jedes Review und jeden Merge mit Zeit, Grund und Links zu den Belegen. Fragen Sie kanman „Warum hast du INT-241 gemergt?“, und es antwortet von dort.