Fehlschlagende Pipelines

Nächtliche Testläufe schlagen fehl, und bei vielen Repositories stapeln sich die E-Mails darüber schneller, als jemand sie liest. kanman liest die Pipelines der Standard-Branches Ihrer Teams, findet heraus, warum sie fehlgeschlagen sind, und kümmert sich darum: eine Story pro Fehler über alle Repositories, die er betrifft, ein Satz zu Ausfällen, die nicht an Ihrem Code liegen, und angehaltene Merges nur dort, wo der Branch rot ist.

Was kanman beobachtet

Jede Stunde liest kanman die neueste Pipeline des Standard-Branches jedes Repositories (der Branch, gegen den das Team arbeitet, meist main oder develop), geplante nächtliche Pipelines eingeschlossen.

• GitHub in der kanman Cloud: kanman sieht Ihre Checks, sobald sie fertig sind.
• GitLab in der kanman Cloud: kanman liest die Pipelines einmal pro Stunde mit der GitLab-Verbindung Ihres Teams, so wie es Ihr Runner tun würde, und der Coding-Agent kann darüber das vollständige Log eines fehlschlagenden Jobs lesen.
• Ein Workspace, der alles auf seinen Runnern ausführt (zum Beispiel ein GitLab hinter einem VPN): Ihr Runner liest die Pipelines mit seinem eigenen Zugang und meldet nur ihren Zustand und kurze, bereinigte Log-Auszüge. Ein Team mit Hunderten Repositories in einer GitLab-Gruppe kostet eine Handvoll Anfragen pro Stunde, nicht eine pro Repository.

Zugangsdaten, Tokens und Passwörter, die in einem Log stehen, werden entfernt, bevor ein Log-Auszug gespeichert wird: auf Ihrem Runner oder in der kanman Cloud, bevor er abgelegt wird.

Warum sie fehlgeschlagen ist

Für jede fehlgeschlagene Pipeline liest kanman das Ende der Logs der fehlgeschlagenen Jobs und ordnet den Fehler einer dieser Arten zu:

Um einen wackeligen Test von einem kaputten zu unterscheiden, startet kanman einen fehlgeschlagenen Job noch einmal, wenn kanman selbst Arbeit hereinholen darf. kanman wiederholt nur Pipelines der letzten drei Tage und höchstens zehn pro Stunde, sodass Ihre CI nie überlastet wird.

Eine Story pro Fehler, nicht pro Repository

Derselbe Fehler in vielen Repositories ist eine Aufgabe: derselbe fehlschlagende Test, derselbe Fehler oder derselbe Ausfall. kanman fasst sie zusammen und legt eine Story an, die jedes betroffene Repository mit einem Link auf seine fehlgeschlagene Pipeline auflistet. Die Story enthält, was fehlschlägt, die fehlschlagenden Tests, einen Log-Auszug, den vorgeschlagenen Fix und Akzeptanzkriterien: Die Pipeline läuft wieder durch, und kein Test wird dafür übersprungen oder abgeschwächt.

• Stories landen in Ready, sodass kanman sie wie jede andere Ready-Story angeht (Ihre Merge-Regeln gelten weiter).
• Ein Team, in dem nur Menschen Stories anlegen, bekommt stattdessen eine Entscheidung pro Fehler.
• Höchstens fünf neue Stories pro Prüfung (die Wartungsgrenze des Teams); der Rest folgt mit den nächsten Prüfungen.
• Ein Fehler, für den schon eine offene Story existiert, ergänzt nur sein Repository in dieser Story.
• Sobald der Fix im ersten Repository gemergt ist, rollt kanman dieselbe Änderung auf die anderen betroffenen Repositories aus (siehe Wartungsmodus).

Die Karte der Story auf dem Team-Board zeigt Pipeline rot in 12 Repositories und verlinkt die neueste fehlgeschlagene Pipeline.

Infrastruktur, an der kanman dranbleibt

Eine Pipeline, die an einer CI-Variable, einem Testkonto beim Anbieter, einem Kontingent, einem Anbieter oder den CI-Runnern scheitert, braucht keinen Fix im Code, ist aber trotzdem Arbeit. kanman erwähnt sie nicht nur und geht weiter: Es übernimmt sie als eigene Arbeit und bleibt dran, bis die Pipelines grün sind.

• Zuerst die Antwort des Anbieters. Bevor kanman jemanden fragt, liest es das Log des fehlgeschlagenen Jobs und findet, was der Anbieter selbst geantwortet hat, zum Beispiel 403 TenantDisabled: „Tenant is disabled.“ oder 429: „You have reached the limit of 30 requests per hour allowed on a Free plan“, statt einer Zusammenfassungszeile der Tests. Diese Antwort bestimmt die Ursache und worum kanman bittet: um einen neuen Wert in den CI-Variablen nur bei widerrufenen, abgelaufenen oder fehlenden Zugangsdaten; um das Reaktivieren des Kontos oder Tenants, wenn der Anbieter es deaktiviert hat; um einen Tarif oder weniger Anfragen bei einem Limit des Tarifs. Hat der Anbieter seine API oder seine Antworten geändert, muss niemand etwas tun: kanman behebt es als eigene Story im Code.
• Ein Eintrag pro Ursache. kanman verfolgt jede Ursache einmal, zum Beispiel „CI-Zugang wiederherstellen: die CI-Variablen VERINICE_E2E_USERNAME und VERINICE_E2E_PASSWORD“, mit allen Repositories, die daran scheitern, auch solchen, die dasselbe Konto oder denselben Tenant beim Anbieter nutzen. Zeigen die Antworten der Anbieter, dass ein Eintrag mehrere Ursachen hat, teilt kanman ihn auf und sagt das im Chat. Die Einträge liegen im Backlog des Teams, kanman zugewiesen, gemeinsam im Ziel CI-Zugang für wiederherstellen. Auf dem Board sagt die Karte des Ziels, worauf es wartet, zum Beispiel Wartet auf die Person, die die CI-Variablen für VERINICE_E2E_USERNAME verwaltet.
• Zuerst im Chat. Jeder Eintrag stellt dem Team eine konkrete Frage, zum Beispiel Wer verwaltet die CI-Variable VERINICE_E2E_USERNAME für die CI von Integrations? Es schlägt seit 5. Okt. in 1 Repository fehl. Die Frage erscheint bei den übrigen Anfragen des Ziels und bietet an:
  • Ich frage : kanman fragt die Person selbst, in kanman und in ihren Slack- oder Teams-Direktnachrichten, wenn sie eines verbunden hat. kanman schlägt die Person vor, die ein ähnliches Problem schon einmal behoben hat, oder die Eigentümer der Repositories in Ihrem Backstage-Katalog.
  • Gib mir die Nachricht zum Senden: eine fertige Nachricht mit allem, was die Person braucht: was seit wann fehlschlägt, die eigene Antwort des Anbieters pro Repository mit einem Link zum Job, die genauen Variablennamen, die Repositories mit ihren fehlgeschlagenen Pipelines und wo der Wert gesetzt wird. Kopieren Sie sie in eine Direktnachricht oder eine E-Mail.
  • zuweisen oder Mir zuweisen.
  • Jemand anderes: Ich sage dir, wer: Nennen Sie die Person; kanman fragt sie, wenn sie in Ihrem Workspace ist, oder richtet die Nachricht an sie.
  • kanman soll die Tests ändern: angeboten, wenn auch eine Änderung im Code hilft, zum Beispiel Live-Tests, die weniger Anfragen senden, um unter dem Limit eines Tarifs zu bleiben. Das ändert Testdateien, deshalb tut kanman es nur mit Ihrem OK.
• Nie ein Geheimnis im Chat. kanman fragt nie nach einem Token oder Passwort. Sind Zugangsdaten die Ursache, bittet es die richtige Person, den Wert dort zu setzen, wo die CI ihn liest, zum Beispiel in GitLab unter Einstellungen > CI/CD > Variablen.
• Nachhaken. kanman prüft jede Pipeline. Ist die Ursache weg, schließt es den Eintrag selbst und sagt es, zum Beispiel Gute Nachricht zu INT-170 (die CI-Variable VERINICE_E2E_USERNAME): Es funktioniert wieder, und 7 von 7 Repositories sind grün. Tut sich zwei Arbeitstage nach dem letzten Schritt nichts, hakt kanman einmal freundlich nach und führt den Eintrag unter den Stories, die auf Menschen warten, bis er grün ist. Die Wartezeit ändern Sie mit Bei CI-Zugang nachhaken nach, im ausklappbaren Teil der Karte Wenn die CI bricht unter Team > Wartung und CI. Die Karte sagt auch in Worten, was kanman für Ihr Team tut, wenn eine Pipeline bricht.

Eine Nachricht pro Tag

In der Unterhaltung des Teams hält kanman eine Nachricht pro Tag aktuell, zum Beispiel:

14 von 534 Repositories sind auf dem Hauptzweig rot: 9 Test- oder Build-Fehler, 4 Infrastrukturprobleme und 1 wackeliger Test. Ich habe 2 Stories angelegt, eine pro Fehler über alle betroffenen Repositories: INT-81 und INT-82. Der Dienst api.example.com antwortet seit 02:00 in 4 Repositories mit Fehlern. Das liegt nicht am Code, deshalb habe ich keine Story dafür angelegt. Betroffene Repositories: acme/billing, acme/crm, acme/shop und 1 weiteres. Wer handeln sollte: niemand im Code. Hält es an, sollte sich die Person, der das Konto beim Anbieter gehört, an den Anbieter wenden.

Infrastrukturprobleme, an denen kanman schon dranbleibt, nennt die Nachricht stattdessen mit ihren Einträgen („Ich verfolge 3 Infrastrukturprobleme als meine eigene Arbeit, bis die Pipelines grün sind: INT-170, INT-171 und INT-172.“); nur ein Problem, das noch niemand verfolgt, bekommt den Satz, wer handeln sollte.

Der Wochenbericht zeigt, wie viele Repositories auf dem Hauptzweig rot sind und wie viele in der Woche rot geworden sind.

Wenn die Änderung von jemand anderem den Branch rot gemacht hat

Manchmal ist die Änderung, die einen Standard-Branch rot gemacht hat, nicht von kanman, sondern von einer Kollegin oder einem Kollegen. kanman überlässt das nicht dem, der es zuerst bemerkt, und schlägt auch keinen Alarm über die Person. Sobald eine Prüfung bestätigt hat, welcher Merge es war:

1. legt kanman eine Korrektur an, oder einen Revert dieser Änderung, wenn eine Korrektur länger dauern würde. Wie jede Änderung von kanman wird sie geprüft, bevor sie gemergt wird.

2. schickt kanman der Person, von der die Änderung stammt, eine Nachricht, in kanman und in ihren Direktnachrichten in Slack oder Teams, wenn sie eines davon verbunden hat, zum Beispiel:

   acme/billing: Der Basis-Branch ist seit deiner Änderung !123 rot. Ich habe !456 angelegt, um es nach vorn zu beheben, und es wird geprüft, bevor es gemergt wird. Soll ich es mergen, oder übernimmst du?

Die Nachricht bietet drei Antworten:

Die Nachricht enthält keine Schuldzuweisung, und niemand sonst bekommt sie in Kopie: weder die Person, der das Team gehört, noch der Kanal. Sie unterbricht auch nie: Sie wartet zusammen mit den anderen Fragen dieser Person und kommt mit ihrer nächsten Zusammenfassung, wenn sie sie nicht vorher öffnet. kanman schreibt nur Personen an, die in kanman Mitglied des Teams sind.

Merges, solange ein Branch rot ist

Ein roter Standard-Branch hält kanmans Merges nur in diesem Repository an. Die anderen Repositories des Teams mergen wie gewohnt. Die Story, die die rote Pipeline repariert, darf mergen: So wird der Branch wieder grün.