Unser GitLab Bot - Chappie

Wir benutzen als Quellcodeverwaltung und Issue-Tracking unserer Projekte eine eigene GitLab Installation. Jeder von uns (Mitarbeitern) hat darauf einen eigenen Benutzer und hat somit Zugriff auf die bei uns gehosteten Kundenprojekte. Im täglichen Betrieb begleiten uns dabei Aufgaben die sich immer gleich wiederholen, wie zum Beispiel das Anlegen eines neuen Kundenprojekts. Diese sind nicht schwierig, aber fordern doch von uns Zeit und Aufmerksamkeit um Fehler zu vermeiden. Auch die zeitliche Verfügbarkeit spielt dabei eine Rolle, manchen Prozesse werden von den Teamleitern getätigt, für manche wird ein Administrator benötigt.

Da viele dieser Aufgaben nach Schema F ablaufen, könnte man diese auch automatisieren. Unsere Lösung dafür ist ein eigener GitLab-Bot, welcher uns diese Arbeiten abnimmt.

Unsere häufigen wiederkehrenden Prozesse

Einer unserer wichtigsten Prozesse im GitLab ist das Erzeugen der Struktur für Kundenprojekte und die anschließende Rechtevergabe. Dabei halten wir uns an eine definierte Struktur mit GitLab Gruppen, die in unseren eigenen Guidelines festgelegt wurde. Die Rechte der einzelnen Projekt-Mitglieder hängt auch entsprechend den Guidelines von ihrer Tätigkeit ab. Projektleiter erhalten zum Beispiel mehr Berechtigungen als QA.

Ein weiterer Prozess, welcher gerne vergessen wird, ist das Hinzufügen neuer Mitarbeiter*innen in unsere Standard-Gruppen. Um Projekte intern zu veröffentlichen benutzen wir bestimmte Gruppen wie pixel-all-developer um allen Mitarbeitern Entwicklungsrechte zu geben. Beim Eintritt eines neuen Mitarbeiters*in wird automatisch von unserer IT ein Benutzer in GitLab angelegt, allerdings ist dieser erst mal für sich allein. Somit muss ein Administrator jeden neuen User in unsere 3 Standard-Gruppen hinzufügen.

Was auch vor allem mich als Administrator oft ereilt ist das Registrieren von GitLab Runnern für ein Kundenprojekt. Wir benutzen inzwischen für die Continious Integration in unseren selbst gehosteten Projekten die GitLab CI Umgebung. Diese bietet uns an über eine Konfigurationsdatei eine beliebige Build-Pipeline aufzubauen und auf registrierten Maschinen, den GitLab-Runnern, auszuführen. Als Standard hat ein Projekt keinen GitLab Runner, diese müssen bei Bedarf von einem Administrator für ein Projekt registriert werden.

Die Umsetzung mit dem GitLab-Bot Chappie

Um die genannten Prozesse anzustoßen, erhält Chappie ein eigenes GitLab-Projekt, welches seine Aufgaben enthält. Aufgaben werden als Issues angelegt und für jeden Prozess gibt es eine Vorlage, welche bei der Erzeugung ausgewählt wird.

Jede diese Vorlagen enthält eine kurze Beschreibung was das fertige Issue auslösen wird und einen Metadata Bereich am Ende. Dieser Block teilt Chappie letztendlich alle benötigten Informationen mit. Kommentare darin helfen dem Ausfüllenden die richtigen Angaben einzutragen. Jedes Issue-Template weist automatisch der neuen Aufgabe ein Label zu, welches den Prozesstyp beschreibt. Abschließend ist das fertige Ticket noch dem Chappie-Benutzer zuzuweisen, entweder bei Erstellung oder nachträglich.

Chappie bearbeitet beim nächsten Durchsuchen aller offenen Issues im Kontroll-Projekt die Aufgabe. Feedback bei Fehlern und die Erfolgsmeldung werden von ihm über Kommentare in den Issues kommuniziert. Im Fehlerfall wird auch der Autor des Issues zugewiesen, so das GitLab eine E-Mail an den betreffenden Benutzer verschickt. Ist der Prozess abgeschlossen, wird das Issue ebenso geschlossen.

Automatische Prozesse

Das beschriebene Vorgehen deckt somit manuell ausgelöste Vorgänge ab, für eventbasierte Aufgaben ist noch ein weiterer Schritt implementiert. Chappie überwacht dafür periodisch für die Aufgaben relevante Informationen und erstellt bei passenden Umständen automatisch ein Issue. Um das am Beispiel der Standard-Benutzergruppen zu erklären: Chappie überprüft die Gruppen jeden Benutzers auf die jeweils passenden Standards. Da wir gemeinsam mit unserer Schwester-Firma GitLab nutzen ist hier die Firmenzugehörigkeit im Bezug auf die richtigen Benutzer-Gruppen wichtig. Unterschieden werden können diese über die Informationen unseres Active Directories. GilLab ist an dieses für die Authentifizierung angebunden und kennt somit die Gruppenzugehörigkeiten in der Domäne. Die werden jetzt genutzt um auf den richtigen GitLab-Standard-Gruppen prüfen zu können. Hat ein Benutzer eine oder mehrere Gruppen nicht, erstellt Chappie automatisch ein Issue in seinem Kontrollprojekt. Dieses ist bereits vorausgefüllt und dem jeweiligen Firmen-Administrator zugewiesen, um auch wieder eine Notification auszulösen. Er kann nun den Prozess wie bereits erklärt Chappie zuweisen und dieser führt die Gruppen-Zuweisung aus.

Externe Systeme

Für manche Aufgaben von Chappie muss in andere Systeme eingegriffen werden. Aktuell ist das für das Einrichten von GitLab Runnern nötig, wofür diese auf unseren Buildservern registriert werden müssen. Um für die Erst-Implementierung keine SSH-Verbindung zu den Servern aufbauen zu müssen, generiert Chappie vorgefertigte Shell-Scripte. Diese sind von einem Administrator manuell auf den jeweiligen Servern auszuführen. Um ihn zu informieren wird das Issue ihm zugewiesen und er bekommt dadurch eine E-Mail Benachrichtigung. Nach der Ausführung liegt es dann auch an ihm das Issue zu schließen.

Ausblick

Der aktuelle Stand unseres GitLab-Bots vereinfacht uns schon jetzt den Administrator Alltag und ist nur der erste Schritt zu weiterer Unterstützung. Denkbar als Erweiterungen sind aktuell die automatische Generierung von Kundenprojekt-Readme Dateien oder die Einbindung unseres Sonatype Nexus. Die Erweiterbarkeit ist bei Chappie nur durch den Aufwand in der Implementierung der Prozesse begrenzt.

Auch ist eine weitere Entlastung unserer GitLab-Administratoren denkbar, da weitere Benutzer für ihre Projekte "Self-Service" betreiben können. Durch das Kontrollprojekt von Chappie lassen sich zeitnah und unabhängig Prozesse anstoßen, welche sonst der Administrator manuell ausgeführt hätte.