Immer up2date mit Quarkus Applikationen

Vor kurzem durften wir eine gar nicht so alte Quarkus Applikation updaten. Die Aufgabe war von 2.5.x auf 3.5.x zu heben. Ein Prozess, der eigentlich ständig durchgeführt werden sollte. Diesen haben wir jedoch aus Gründen der Feature Entwicklung hinten angestellt. Wie jede:r brave Entwickler:in setzt man sich hin und liest die Release Notes und, da Quarkus es bietet, die Migration Guides. Weiteres Googeln nach möglichen Lösungen zeigte schnell, dass Quarkus sich selbst updaten kann! Die genauen Details können bei Quarkus direkt nachgelesen werden. TL;DR: Es ist ein Maven Goal `quarkus:update`, das mit OpenRewrite den Code transformiert. Viel einfacher kann man es Entwickler:innen wirklich nicht machen. Die eine oder andere Stelle musste manuell ausgebessert werden, aber das war nicht weiter aufwendig.

OpenRewrite ist eine Technologie, die wir uns in Zukunft sicher genauer anschauen werden.

Entwickler:innen 1x in der Woche manuell das Maven Goal ausführen lassen? Wohl eher nicht… Da wir natürlich für unsere Projekte gute Automatisierungen und Pipelines haben, können wir Folgendes machen:

• 1x in der Woche gibt es eine Pipeline, die den Code ‘auscheckt’ und über Maven das Quarkus Update ausführt.
• Da die pom.xml, Java Dateien usw. automatisch geändert werden, können wir auch gleich das Projekt bauen, testen, deployen, usw.
• Wenn alles gut gegangen ist, pushen wir die Änderungen in einen Branch und erstellen einen Merge Request, der die Änderungen zeigt.
• Ein oder mehrere Entwickler:innen können den Merge Request reviewen und mergen.

Damit das funktioniert, braucht man eine hohe Testabdeckung. Nicht nur seitens Unit Tests, sondern auch Integration- und UI-Tests. Aber mal ganz ehrlich, wer hat das nicht 😉

Bei vielen unserer Kund:innen sehen wir immer öfter, dass Updates zu einem großen Problem werden. Security Abteilungen bestehen auf Framework-/Runtime-Updates, welche teilweise nicht möglich sind ohne hohen Aufwand hineinzustecken. Auch gefährliche Security Vulnerabilities, wie Log4Shell, sind dann nur schwer zu lösen. Wir müssen aus einem Reagieren zu einem Agieren kommen. Ich kann Updates und Änderungen einplanen und dementsprechend ein Budget schaffen. Auch sind öfter kleinere Updates viel leichter durchzuführen als große in weiteren Abständen. Wenn es dann wirklich mal aufwendiger wird, braucht man nicht X Seiten von Release Notes durchsehen, sondern nur wenige.