Die technische Seite des Neos Release-Prozesses ist eine wilde Mischung aus automatisierten und manuellen Aufgaben. Einige Bereiche sind gut dokumentiert und andere sind nur den Stammesältesten bekannt. Tatsächlich war ich wahrscheinlich derjenige, der einen umfassenden Überblick über den Prozess und die Tools hatte... bis zu dieser Woche.
Auf Einladung von sitegeist trafen wir uns in Hamburg zu einem Sprint zum Thema "Release Process", einem kleinen, aber feinen Sprint, der sich der Verbesserung des Release-Prozesses, seiner Dokumentation und seiner Tools widmete. Unter der Moderation von Gina diskutierten drei Entwickler (Martin, Wilhelm und ich) über den bestehenden Prozess und entwarfen einen Plan, um ihn zu verbessern. Leider konnten Gerhard und Christian nicht nach Hamburg kommen, aber zumindest wissen wir jetzt schon, dass mehr Leute für die Zukunft an Bord sind...
Wir begannen am Donnerstag mit einem EventStorming session, um den Release-Prozess zum ersten Mal überhaupt zu visualisieren. Obwohl ich die Event-Karten (größtenteils) vorher vorbereitet hatte und den Prozess kannte (weil ich ihn selbst schon ein paar Mal gemacht und anderen geholfen hatte), war ich trotzdem überrascht. Es ist unglaublich, wie sehr diese Methode dabei geholfen hat, einen Stapel Notizen in eine visuelle Darstellung eines klar definierten Prozesses zu verwandeln, komplett mit Schlüsselaggregaten, Hotspots, Befehlen und einigen weiteren Details.
Am Freitag haben wir einige Zeit damit verbracht, die Hotspots zu besprechen, die wir identifiziert hatten. Was ist in der Vergangenheit schief gelaufen, wo kann etwas schief gehen und warum. Und selbst wenn etwas schief geht, was sind die Folgen - beeinträchtigt es die Veröffentlichung in einer Weise, die es rechtfertigt, es zu blockieren? Und zu guter Letzt: Gibt es Möglichkeiten, die Ergebnisse der Schritte zu testen? Können wir sie automatisieren?
Natürlich werden einige Schritte manuell bleiben, es gibt Aufgaben, die von Menschen erledigt werden müssen. Ein Beispiel ist die Dokumentation und Kommunikation rund um ein Minor- oder sogar Major-Release, aber auch die Entscheidung, die Veröffentlichung einer neuen Version tatsächlich auszulösen. Aber die meisten der derzeit manuellen Schritte können sowohl getestet als auch automatisiert werden, einige erscheinen in dieser Hinsicht sogar fast trivial. Das lässt uns hoffen, dass wir die "Stellenbeschreibung" für Release Manager/innen deutlich reduzieren können.
Da wir den Prozess in einer Pipeline modellieren wollen (wie du es vielleicht von GitLab oder Jenkins kennst), um alle automatisierten Aufgaben auf leicht verständliche Weise mit allem, was manuell erledigt werden muss, zu verknüpfen, haben wir besprochen, was wir dafür brauchen würden. Nach einem kurzen Blick in die "Pipeline as Code" von Jenkins waren wir uns einig, dass das funktionieren könnte.
Nach einer Pause begannen wir, eine erste Liste mit Aufgaben und Notizen aufzuschreiben und den Prozess zu skizzieren, den wir uns vorgestellt hatten. Da einige dieser Punkte bereits bekannt waren und sogar als GitHub-Probleme existierten, entschieden wir uns für GitHub als zukünftige Heimat für alles, was mit dem Veröffentlichungsprozess zu tun hat. In einem neuen Repository werden die Issues, der Code und die Dokumentation zum Veröffentlichungsprozess gespeichert (also die technische Seite, im Gegensatz zur "öffentlichen Ansicht"). Wir haben ein Projektboard eingerichtet, einige Labels definiert und alle bestehenden relared Issues in ihr neues Zuhause übertragen.
Unser nächster Schritt ist die Umwandlung der ToDo-Punkte aus dem Sprint in Aufgaben, die beschriftet und bereit sind, gelöst zu werden. Die zweite Aufgabe, die wir für den ersten unserer Meilensteine lösen müssen, ist die Evaluierung von Jenkins als Pipeline-Lösung abzuschließen. Wenn uns nichts aufhält, werden wir an den nächsten Meilensteinen wie geplant weiterarbeiten und Gerhard und Martin können Neos 4.3 (zusammen mit Flow 5.3) mit einer glänzenden neuen Build-Prozess-Toolchain veröffentlichen.