Automatische Updates in unseren Projekten

Der typische IT-ler ist sein Schicksal manchmal selbst schuld: Wir beschäftigen uns am liebsten mit spannenden Herausforderungen, Technologien und Software-Stacks oder suchen nach neuen Dingen, die wir unseren Kunden verkaufen können. Irgendwann holt uns aber natürlich dann das Tagesgeschäft ein und wir müssen die ganzen Applikationen, die wir entworfen haben, auch noch betreiben. Dazu gehört dann auch das Einspielen von Updates und Sicherheitspatches für die verschiedenen 3rd-Party-Komponenten, die dabei zum Einsatz kamen. Aber mal ehrlich: Wer macht so etwas schon gerne?

Hinzu kommt, dass mit wachsender Komplexität die Häufigkeit, in der Updates anstehen, natürlich auch enorm ansteigt. Da ist es gar nicht so ungewöhnlich, dass im Schnitt alle zwei Tage in praktisch jedem Projekt irgendetwas zu tun ist. Und nicht zuletzt muss das Ganze auch irgendwie noch von irgendjemandem getestet werden.

Es bringt aber auch nichts, die Updates auszusitzen. Zum einen bringen Updates oft Verbesserungen mit sich, etwa in Sachen Performance. Zum anderen ist man nach aktueller Rechtslage ohnehin verpflichtet, regelmäßig für aktuelle Softwarestände zu sorgen.

Kanban-Karte für TYPO3-Update auf 8.7.30
Kanban-Karte für TYPO3-Update auf 8.7.30

Kleinschrittige Updates, aber bitte ohne Monsterbürokratie

Nun praktiziert die MFC seit Anfang 2019 bekanntermaßen Kanban. Da gehört es zum Konzept, dass jeder Mitarbeiter sich selbst die nächste Aufgabe sucht. Unnötig zu sagen, dass sich die Update-Karten nicht unbedingt großer Beliebtheit erfreuen. Logisch: Was im Prinzip nur ein composer update , gefolgt von ein bisschen Git-Geplänkel ist, ist natürlich nicht so spannend, wie die anderen Aufgaben, die es vielleicht gerade noch gibt. Man ist ja Problemlöser.

Und genau, weil wir gerne Probleme lösen, musste hier dringend etwas passieren, frei nach dem Motto: "Automate the Boring Stuff". Herausgekommen ist ein kleines Skript, das mehrere Dinge tut:

  1. Täglich läuft ein composer update im Projekt. Das Ergebnis wird in einem neuen Branch namens support/autoupdate committet.
  2. Sofern der Branch bereits existiert, überschreibt das Skript den bestehenden mit dem aktuellen Stand. Dadurch sammeln sich alle anstehenden Updates in einem Branch.
  3. Zum Schluss wird ein Merge Request in GitLab im Projekt angelegt und dem zuständigen Projektleiter zugewiesen. Dieser kann die hochgezogene Applikation testen und den Branch per Klick mergen.

Der gesamte Prozess läuft arbeitstäglich in der Nacht, d.h. wenn man morgens ins Büro kommt, sind die Update-Branches schon fertig und warten aufs Testen. Wir Entwickler werden damit bei Updates eigentlich nur noch im Fehlerfalle benötigt oder maximal noch, um am Ende ein Release zu erzeugen. Während die Projektleiter fleißig die – unausweichliche – Flut an anstehenden Updates QS-sen, können wir uns daher wieder den eigentlichen Herausforderungen widmen.

Das Autoupdater-Skript ist in PHP geschrieben, existiert allerdings aktuell nur in Form eines nicht "vorzeigbaren" Proof-of-Concept 😉 Wir arbeiten gerade daran, das Tool so weiter zu entwickeln, dass wir es auf GitHub opensourcen können. Sobald das geschehen ist, aktualisieren wir diesen Blogbeitrag.
Update: Unseren Autoupdater findest du inzwischen auf GitHub.

Übrigens, wenn du der Meinung bist "Das kann ich auch!", dann bewirb dich doch bei uns!