Wartungsmodus

Die meisten Teams kennen ihren Wartungs-Backlog und kommen nie dazu. Der Wartungsmodus, die eingebaute Habit Abhängigkeiten und Sicherheit aktuell halten, ist die proaktive Seite von kanman: Er prüft die Repositorys des Teams regelmäßig und führt eine Liste seiner Funde. Findet ein Scan etwas Neues und Ernstes (einen kritischen oder hohen Fund), liest kanman es wie jede andere Neuigkeit über das Team und entscheidet, ob daraus eine Story wird. Diese Story durchläuft dann dieselben Prüfungen, dasselbe Review und dasselbe Budget wie alles andere. Du kannst auch selbst jeden Fund zur Story machen.

Einschalten

Wartung ist die eingebaute Habit Abhängigkeiten und Sicherheit aktuell halten im Reiter Habits des Teams. Öffne sie, um zu sehen, ob sie an ist, und ihre letzten Scans. Zum Einschalten oder Pausieren sag es kanman im Chat des Teams, zum Beispiel „halte unsere Abhängigkeiten und die Sicherheit aktuell“ oder „pausiere die Wartung bis nach dem Release“. Ändern können sie nur die Owner und Leads des Teams.

kanman gibt der Wartung selbst das Tempo vor: ein paar neue Wartungs-Stories am Tag und höchstens einige pro Scan, und jedes Repository etwa einmal pro Woche gescannt, damit die übrige Arbeit des Teams weiterläuft. Sicherheitsfunde kommen zuerst.

Der geplante Scan läuft nachts (UTC). kanman sagt es dem Team im Team-Chat, wenn ein Scan nicht laufen konnte, zum Beispiel weil keiner deiner Runner online war. Sonst bleibt ein geplanter Scan still; was er gefunden hat, steht in der Liste, und kanman sieht sich die neuen ernsten Funde selbst an (siehe Was mit den Funden passiert). Pausierte Teams werden nicht gescannt.

Jetzt scannen

Du musst nicht auf den Scan-Tag des Teams warten. Bitte kanman im Chat des Teams darum, zum Beispiel „Prüf das Repo auf veraltete oder unsichere Abhängigkeiten“, „Gibt es kaputte Links in der Doku?“ oder ausführlicher „Such im Repo nach Wartungsarbeit: unsichere oder veraltete Abhängigkeiten, ungenutzte Abhängigkeiten, Lockfile-Drift und kaputte Doku-Links. Leg an, was du findest, damit ich es prüfen kann.“ kanman startet einen Scan, statt Stories zu entwerfen, die solche Prüfungen bauen: Der Scan ist diese Prüfung. Das funktioniert genauso aus Slack oder Microsoft Teams und wenn du kanman in einem Pull oder Merge Request erwähnst. Die Antwort trägt eine Karte, die dem Scan folgt und die Funde nach Art zählt, sobald er fertig ist. Eine erneute Bitte, während ein Scan läuft, startet nie einen zweiten. Starten können einen Scan nur Owner und Admins; andere bekommen einen kurzen Hinweis, wo die letzten Funde stehen. Jeder Scan steht im Audit-Log und unter den Runs der Habit.

Ein neues Team wartet auch nicht: Sobald die Wartung an ist und ein Repository verknüpft ist, läuft der erste Scan innerhalb weniger Minuten.

Zusammen mit Renovate und Dependabot

Viele Teams lassen ihre Abhängigkeits-Updates schon von Renovate oder Dependabot öffnen. kanman bemerkt das selbst, pro Repository: an einer Renovate-Konfiguration (renovate.json, .renovaterc und ähnliche oder ein Abschnitt renovate in package.json), an .github/dependabot.yml oder an Merge Requests, die der Bot geöffnet hat. Einzurichten gibt es nichts, und es funktioniert auf GitLab (Renovate) und GitHub (Renovate und Dependabot).

Bemerkt kanman einen Bot zum ersten Mal, oder kommt ein Bot hinzu oder fällt weg, sagt es das einmal im Team-Chat, zum Beispiel: „Mir ist aufgefallen, dass Renovate die Abhängigkeits-Updates in api-gateway öffnet. Ich öffne dort also keine eigenen mehr und kümmere mich stattdessen um seine Merge Requests. Sag Bescheid, wenn ich weiter eigene öffnen soll.“ Deine Antwort merkt sich kanman für dieses Repository.

In einem Repository, in dem ein Bot die Updates öffnet:

• Keine Duplikate. kanman öffnet dort keine eigenen Versions-Updates. Der Bot bleibt die einzige Quelle für Updates; veraltete und verwundbare Abhängigkeiten, die kanman findet, überlässt es den Merge Requests des Bots.
• Ein kurzes Review zu jedem Bot-Merge-Request. kanman liest die Änderung und ihre Release Notes und sagt, was sie für deinen Code bedeutet, zum Beispiel „Patch, unbedenklich“ oder „Breaking Change bei den Client-Optionen, an zwei Stellen in billing verwendet“.
• Rote CI behoben. Schlägt die Pipeline eines Bot-Merge-Requests fehl, findet kanman heraus, warum, und baut die Korrektur auf dem Branch des Bots auf.
• Major-Updates erledigt. Braucht eine neue Major-Version Codeänderungen, macht kanman sie, ebenfalls auf dem Branch des Bots.
• Einmal pro Bündel freigeben. Ähnliche Updates, etwa dieselbe Bibliothek in mehreren Repositorys oder eine Reihe von Patch-Updates, kommen als eine Frage zur Freigabe, nicht einzeln. Hat eine Person mit Schreibrechten das Bündel freigegeben, mergt kanman die Merge Requests nacheinander, jeden nur mit grüner CI. Major-Updates kommen immer einzeln.
• Sicherheitsfunde mit Nachweis geschlossen. Wird ein Bot-Merge-Request gemergt, der eine Schwachstelle behebt, schließt kanman den Fund und verlinkt den Merge Request als Nachweis.
• Hängende Updates im Brief. Bot-Merge-Requests, die seit Tagen auf eine Freigabe warten oder seit mehr als einer Woche offen sind, stehen mit Grund und Link im wöchentlichen Brief der Team-Leads.

Der Text eines Bot-Merge-Requests und die Release Notes, die er zitiert, kommen von außerhalb deines Teams. kanman liest sie als Information, nie als Anweisung.

Wonach kanman sucht

kanman liest die Repositorys aus allowed_repos des Teams auf GitHub oder GitLab, ohne sie zu klonen und ohne in sie zu schreiben.

Scanner sind deterministische Werkzeuge, nicht die Meinung eines Modells:

Die Abhängigkeits-Scanner decken npm, Python (pip, Poetry, uv), Rust (Cargo), Go-Module und Java oder Kotlin (Maven, Gradle) ab. Fest angegebene oder gesperrte Versionen werden gegen die öffentlichen Paket-Registries auf neuere Versionen und gegen eine öffentliche Schwachstellen-Datenbank auf bekannte Schwachstellen geprüft.

Ungenutzte Abhängigkeiten und veraltete Feature-Flags brauchen das ganze Repository. Deshalb führt kanman einmal am Tag zusätzlich einen rein lesenden Scan auf einer frischen Kopie jedes verknüpften Repositorys aus. Er ändert das Repository nie, pusht keinen Branch und öffnet keinen Pull Request.

• Ungenutzte Abhängigkeiten: Abhängigkeiten, die nichts in deinem Code importiert oder erwähnt. Ein Paket gilt als genutzt, wenn ein Skript in der package.json seinen Befehl aufruft (tsc für TypeScript, playwright für Playwright), wenn ein Testbefehl oder die Testkonfiguration Coverage einschaltet (für @vitest/coverage-*), wenn eine Konfigurationsdatei des Werkzeugs existiert (postcss.config.js, tailwind.config.ts, .eslintrc, vite.config.ts und ähnliche) oder wenn ein genutztes Paket es als Peer-Abhängigkeit braucht (PostCSS für Tailwind CSS und Autoprefixer). Ein Typpaket wie @types/lodash wird zusammen mit seinem ungenutzten Paket gemeldet. Ungenutzte Pakete einer Familie, zum Beispiel @codemirror/* und die CodeMirror-Pakete von @uiw/*, werden ein einziger Fund, damit das Entfernen eine Story ist.
• Veraltete Feature-Flags: Flags, die definiert, aber nie genutzt werden, Flags, die seit 90 Tagen dauerhaft an oder aus sind, und Flags, die seit mehr als sechs Monaten im Code abgefragt werden.

Teams mit einem Self-hosted Runner führen diesen Scan auf ihrem eigenen Runner aus.

Reviewer lesen, ohne etwas zu ändern. Jeder Scan führt einen davon aus, im Wechsel: Nacharbeiten nach dem Merge, ein Architektur-Review, veraltete Dokumentation und Testqualität. Sie sehen sich aktuelle Runs und einige Dateien an. Ihre Befunde kommen wie alle anderen in die Liste.

SonarQube. Hat das Team SonarQube verbunden (Team > Verbindungen > Alarmquellen), liest kanman alle paar Stunden auch die offenen Probleme in neuem Code und ein fehlschlagendes Quality Gate auf dem Standard-Branch jedes Repositorys, jeweils einen Teil der Repositorys. Sie kommen wie die Funde der Scanner in die Liste, jedes Problem einmal pro Regel, Datei und Zeile.

Die Funde erscheinen im Reiter Stories des Teams unter Wartungsfunde, gruppiert danach, was mit ihnen passiert: Noch nicht angesehen, In Stories, Zurückgestellt, Verworfen und Behoben, jeweils mit ihrer Zahl. Große Gruppen öffnen sich nach Art und dann nach Repository, so bleibt auch eine Liste mit tausend veralteten Abhängigkeiten lesbar. Jeder Fund sagt in Worten, was mit ihm passiert, zum Beispiel Als INT-123 angelegt (ein Link zur Story), Mit zusammengehörigen Funden in INT-130 gebündelt, Verworfen: Fehlalarm mit kanmans Notiz, Zurückgestellt bis 1. Nov. mit dem Grund oder Noch nicht angesehen: kanman sieht sich neue Funde in seiner nächsten Runde an. Ein Fund, den ein späterer Scan nicht mehr sieht, ist Behoben.

Eine Story pro Korrektur, über Repositorys hinweg

Teams mit vielen Repositorys teilen oft Abhängigkeiten und Code-Muster, deshalb findet ein Scan dasselbe immer wieder. kanman legt eine Story pro Korrektur an, nicht eine pro Repository: Nutzen zehn Services dieselbe unsichere Version von golang.org/x/net, bekommst du eine Story, “golang.org/x/net in allen betroffenen Repositories auf v0.56.0 aktualisieren”, mit den zehn Repositorys darin.

Befunde gehören zusammen, wenn sie dieselbe Korrektur brauchen:

• Unsichere Abhängigkeiten: dasselbe Paket mit denselben Sicherheitswarnungen. Die Story nennt die Version, die alle behebt.
• Veraltete und ungenutzte Abhängigkeiten: dasselbe Paket und dieselbe Zielversion.
• Regelbasierte Befunde wie nicht synchrone Lockfiles, kaputte Links in der Dokumentation, zu große Module oder veraltete Feature-Flags: dieselbe Regel an derselben Stelle, zum Beispiel dasselbe kaputte Linkziel.
• Review-Befunde in Alltagssprache: Befunde, die dasselbe mit anderen Worten sagen, verglichen nach ihrer Bedeutung.

Die Story hält die Liste der betroffenen Repositorys aktuell, jeweils mit Version oder Datei:

• Findet ein späterer Scan dasselbe in weiteren Repositorys, ergänzt er sie in der offenen Story. Es entsteht keine neue Story und keine neue Karte im Chat.
• Ein Repository, in dem der Scan es nicht mehr findet, fällt aus der Liste. Ist die Liste leer, schließt kanman die Story als nicht mehr zutreffend.
• Derselbe Befund zweimal in einem Repository, etwa in zwei Manifesten, ist ein Eintrag.

Eine gebündelte Story ausführen. Ein Run ändert immer ein Repository und öffnet einen Merge Request. Die Story zeigt, an welchem Repository ihr nächster Run arbeitet: zuerst an der gemeinsamen Vorlage, wenn sie selbst betroffen ist, dann am schwerwiegendsten. Braucht es dieselbe Änderung in vielen Repositorys, plant kanman die Arbeit über alle selbst, ein Merge Request pro Repository, jeder von der CI geprüft und vor dem Merge reviewt.

Gemeinsame Vorlagen. Brauchen drei oder mehr Repositorys dieselbe Korrektur, schlägt die Story vor, sie auch in der gemeinsamen Vorlage zu machen, damit neue Repositorys das Problem nicht wieder mitbringen. kanman erkennt ein Repository, das wie eine Vorlage oder ein Deployment-Repository neben den betroffenen heißt; sag es kanman im Chat, wenn es sich irrt.

Ein Team mit nur einem Repository funktioniert genauso: Wiederholte Befunde werden trotzdem eine Story.

Was mit den Funden passiert

Ein Scan meldet nur. Er legt von sich aus keine Stories an und schließt keine:

• Neue kritische oder hohe Funde erreichen kanman direkt nach dem Scan, jeweils mit einer kurzen Zusammenfassung. kanman sieht sie sich neben allem an, woran das Team arbeitet, und entscheidet: eine Story für ein echtes Risiko, eine Notiz an einer Story, die es schon abdeckt, oder nichts, wenn der Fund für deinen Code keine Rolle spielt. Seine Entscheidung und der Grund stehen in der Aktivität des Teams, wie jeder andere Schritt.
• Jeden neuen Fund sieht sich kanman in seiner nächsten Runde an, die schwersten zuerst. kanman entscheidet über jeden und nennt den Grund: eine Story, eine gemeinsame Story für zusammengehörige Funde (etwa dieselbe Abhängigkeit in vielen Repositorys), zurückgestellt bis zu einem Datum oder Ereignis, oder verworfen als Fehlalarm, akzeptiertes Risiko, nicht zutreffend oder doppelt. Einen großen Rückstand arbeitet kanman über mehrere Runden ab. Jede Entscheidung steht in der Aktivität des Teams, und Warum antwortet daraus.
• Ein zurückgestellter Fund kommt zu kanman zurück, wenn sein Datum kommt, oder spätestens nach 30 Tagen, wenn er auf ein Ereignis wartet.
• Ein Fund, den ein späterer Scan nicht mehr sieht, gilt in der Liste als erledigt. Stories bleiben, wie sie sind: kanman hält das Board selbst aktuell, und du kannst eine Story jederzeit schließen.

Wenn du einen Scan anstößt (Jetzt scannen oder im Chat), nennt kanman dir das Ergebnis, sobald er fertig ist, zum Beispiel “Ich habe acme/app gescannt: 2 Ergebnisse.” oder bei vielen Repositorys “Ich habe 10 Repositories gescannt: 10 verwundbare Abhängigkeiten und 2 veraltete Abhängigkeiten.”

Mit einem Fund arbeiten

Öffne den Reiter Stories des Teams und dort Wartungsfunde. Klicke auf einen Fund, um seine Details neben der Liste zu öffnen: warum kanman ihn meldet und welche Belege es gefunden hat, etwa das Paket, das Manifest, Versionen, Sicherheitswarnungen, Datei und Zeile, und wann er zuerst und zuletzt gesehen wurde. Owner und Admins können direkt dort handeln:

• Jetzt als Story anlegen legt die Story sofort an, außerhalb des täglichen Limits, weil du entschieden hast. Der Fund wechselt zu In Stories und verweist auf seine Story. Ist dieselbe Korrektur für andere Repositorys schon als Story offen, kommt der Fund zu dieser Story.
• Verwerfen fragt nach einem kurzen Grund. kanman legt den Fund nie wieder an und schlägt ihn nicht mehr vor.
• Kein Befund nimmt einen optionalen Grund und setzt den Fund für dieses Repository auf die Ignorierliste des Teams: Spätere Scans überspringen ihn ganz. Nutze das für Fehlalarme.

Jede dieser Aktionen steht im Audit-Log.

Leitplanken

• Scans lesen nur. Ein Scan ändert nie ein Repository, pusht keinen Branch und öffnet keinen Merge Request.
• Keine Duplikate. Jeder Befund hat einen Fingerabdruck, wird also einmal gespeichert und beim erneuten Sehen gezählt. Befunde, die dieselbe Korrektur brauchen, teilen sich über Repositorys hinweg eine Story (siehe Eine Story pro Korrektur).
• Gleiche Prüfungen, gleiches Budget. Wartungs-Stories laufen durch deine CI und das unabhängige Review und zählen wie jede andere Story zum Budget des Teams.
• Scanner-Texte sind Daten. Titel und Sicherheitswarnungen kommen von außerhalb deines Teams. kanman liest sie als Information, nie als Anweisung.

Vorschläge für größere Änderungen

Bei eingeschalteter Wartung liest außerdem ein Stratege alle drei Tage STRATEGY.md, docs/STRATEGY.md oder .kanman/STRATEGY.md in deinem Repository und schlägt bis zu drei Features vor, jeweils mit dem Ziel, dem es dient, Nutzen, Aufwand, Risiko und Alternativen. Jeder Vorschlag ist eine Entscheidung Strategievorschlag: Start intake macht daraus eine Anforderung des Teams, die wie jede andere eingeordnet und entworfen wird; Decline merkt sich kanman und schlägt dieselbe Idee nicht erneut vor. Teams ohne Strategie-Datei bekommen keine Vorschläge.

Wenn die CI bricht

Was kanman tut, wenn eine Pipeline auf einem Default-Branch fehlschlägt, ist die eingebaute Habit Main im Blick behalten im Reiter Habits. Siehe Fehlschlagende Pipelines.

Verwandte Seiten

• Richtlinien, Presets und Befugnisstufen
• Budgets und Kosten