Don’t touch it! Wie wir mit unseren Automatisierungslösungen dafür sorgen, dass niemand Tickets „anfassen“ muss

In unserem vorherigen Blogartikel haben wir schon davon berichtet, wie uns der Dependencybot Arbeit bei der Entdeckung und Meldung von Sicherheitslücken abnimmt. Heute würde ich Ihnen gerne einen weiteren digitalen Kollegen vorstellen, den Issuebot. Bevor wir zur Vorstellung kommen, hier noch ein paar Hintergrundinformationen:

In unseren agilen Entwicklungsprojekten sind die Aufgaben in Form von Tickets beziehungsweise Issues festgehalten – in den meisten Projekten von uns verwenden wir dazu GitLab. Nachdem sie das Refinement durchlaufen haben, haben sie in der Regel eine Qualität erreicht, sodass es keine offenen Fragen mehr zu ihnen gibt. Sind sie dann für einen Sprint eingeplant, durchlaufen in diesem Zeitraum unterschiedliche Phasen auf unseren Kanban-Boards:

Die Aufgabe liegt im Sprint-Backlog und kann durch Umsetzer gezogen werden (Pull-Prinzip)

Manuelle Statuspflege? Das übernimmt der Issuebot.

Um den Überblick über den aktuellen Stand zu haben, ist es wichtig, den Status des Tickets zu pflegen. Ist dies eine manuelle Aufgabe, wird es häufig vergessen. Und so passiert es immer wieder, dass ein Ticket noch in der To-do-Spalte steht, obwohl die Inhalte umgesetzt oder sogar schon deployed sind.

Der Issuebot nimmt uns diese lästige manuelle Arbeit ab und sorgt dafür, dass die Tickets im richtigen Status sind. So muss ein*e Entwickler*in im Regelfall ein Ticket nicht mehr „anfassen“, wie im Änderungsprotokoll zum Ticket zu sehen ist.

In der ersten Zeile wird ein Commit mit Erwähnung des Tickets registriert. Darauf lauscht der Issuebot, sieht, dass die Umsetzung begonnen hat, und passt den Status an. Danach wird die Lösung durch den/die Entwickler*in in Form eines Merge Request bereitgestellt, damit diese Lösung im Anschluss an die Qualitätssicherung durch ein weiteres Teammitglied mit der Code-Base zusammengeführt werden kann (Vier-Augen-Prinzip). Auch das bekommt der Issuebot mit und passt wiederum den Status auf „In Review“ an. Zuletzt wird nach abgeschlossener QS und dem erfolgreichen Merge der Status automatisch auf „Reviewed & deployed“ gesetzt.

Hier unterscheiden sich dann die Workflows in den Teams. Ist zum Beispiel der Fachbereich und/oder die UX in der QS im Status „In Review“ involviert, wird der Issuebot für dieses Projekt auch so konfiguriert, dass er nach dem Merge das Ticket direkt schließt.

Der Issuebot selbst besteht aus mehreren Python-Modulen und wird zentral ausgeführt. Durch das „Einladen“ des Issuebots als Member in das entsprechende GitLab-Projekt und das Setzen eines Webhooks wird er für das Projekt scharfgeschaltet. Wenn die Standardkonfiguration nicht ausreicht, kann er, wie oben beschrieben, projektindividuell konfiguriert werden.

Meine Kolleg*innen und ich möchten den Issuebot nicht mehr missen und freuen uns, dass er uns neben dem Dependencybot unser Leben vereinfacht.