Am Ball bleiben - Warum up to date bei Bibliotheken & Co. wichtig ist

Bei der Softwareentwicklung bedient man sich ständig an fertigen Modulen/Frameworks und Bibliotheken. Selbst bei einem Projekt, das auf der sprichwörtlich „grünen Wiese“ startet, programmiert und entwickelt niemand alles komplett selbst.

Dies ist aus mehreren Aspekten heraus sinnvoll – unter anderem lassen sich Kosten minimieren, die Qualität steigt bzw. die Fehleranfälligkeit wird gesenkt und man erhält ein Stück weit Schutz vor Sicherheitslücken. Vorausgesetzt natürlich, man wählt richtig aus dem schier unendlichen Fundus aus Frameworks, Tools, Bibliotheken und kleinen Helferlein.

Doch auch all die Bausteine, die man im Projekt nutzt, entwickeln sich weiter – manche schneller und manche langsamer (und ein paar wenige gar nicht).

Am Ball bleiben bei Updates von Bibliotheken, Frameworks & Co. (© Markus Spiske - Unsplash)

Wie soll man sich im Projekt nun verhalten?

Getreu dem Motto: „Never change a running System! " handeln? Oder ganz klar: „Immer vorne dran bleiben“ ?
Wie so oft – die richtige Antwort lautet: kommt ganz drauf an (und liegt irgendwo dazwischen).

Never change a running System?

Warum soll man etwas verändern, wenn es funktioniert? Meist (so fühlt es sich zumindest an) bringen Updates immer Probleme mit sich. Wenn man sich bewusst oder unbewusst für einen Stack an Frameworks und Bibliotheken entschieden hat, die zusammen gut funktionieren, sollte es doch keine Gründe geben diese auszutauschen. Kurzfristig ist diese Herangehensweise sicher kein Fehler, aber mittel- bis langfristig ergeben sich hier enorme Probleme:

• Erkannte Sicherheitsprobleme bleiben als Einfallstor erhalten
• Neue Features können nicht genutzt werden
• Inkompatibilitäten durch spätere Hinzunahme anderer Bibliotheken, die Versionskonflikte herbeiführen
• Sollte man sich dann doch irgendwann dafür entscheiden Updates durchzuführen, kann dies ein schmerzhafter Prozess sein. (Der Aufwand bzw. die Kosten dafür wurden nur verschoben, das Risiko, dass es zu Problemen kommt, vergrößert sich jedoch stark)

Update  loading (©Clint Patterson - Unsplash)

Immer vorne dran bleiben?

Eigentlich doch eine einfache Sache – von jeder Bibliothek einfach immer die aktuellste und neuste Version nehmen – und das am besten automatisiert… latest eben (npm/maven und co können das ja – wenn man sie lässt). Man hat immer die neuesten Features und Sicherheitspatches sind alle enthalten. Aber auch dieser Ansatz bringt (hier oft sogar kurzfristig) Probleme mit sich:

• Was heute noch ging, kann morgen kaputt sein (und das ohne eine Zeile Code geändert zu haben)
• Selbst „Works on my machine“ (WOM) kann sich in Sekunden ändern (wenn man z.B. im node Ökosystem unterwegs ist und ohne Rücksicht einfach alles zulässt)
• Die ein oder andere Bibliothek reift erst mit dem Einsatz. Hier mit allem vorne dabei zu sein, bedeutet somit auch, in jeden Fehler zu rennen
• Bei Updates vieler Bibliotheken in kurzer Zeit lässt sich kaum noch feststellen, woher ein vermeintliches Problem kommt
• Je nach Ökosystem (in erster Linie npm Module) kann man sich hier durch korrumpierte Module schnell Schadcode in das Projekt ziehen. Ein prüfender Blick auf neu anstehende Updates ist hier zwingend notwendig

Wie nun also vorgehen?

Updates ja, aber nach Plan. Das Projekt braucht einen zur verwendeten Technologie passenden Tool-Stack, der aufzeigt, wo es welche Updates gibt und im besten Fall noch wie kritisch diese Updates sind. Um hier nur ein paar Ansätze zu nennen: renovate, npm outdated, dependabot, usw… am Ende eben ein funktionierendes „Software Dependency Management“.

Es gilt Updates zu planen und zu kommunizieren, sich auf seine Tests verlassen können und generell Versionen bewusst auszuwählen.

Optimales Vorgehen bei Updates von Bibliotheken & Co. (©eXXcellent solutions)

Kommunikation - im Team und auch am Ende mit dem Kunden/Konsument der Software. Wenn bekannt ist, wann Updates stattfinden und klar kommuniziert wird, was betroffen ist, lassen sich ggfs. daraus entstandene Fehler sehr schnell erkennen, eingrenzen und beheben. Seiteneffekte, die man sich durch Updates einfängt, führen dann nicht zu fragenden Gesichtern und panischen Debug-Sessions.

Sinnvoll planen – Updates sollten nicht zum Sprintende oder kurz vor Codefreeze stattfinden, sondern immer so früh wie möglich in einer „neuen“ Phase (bspw. dem neu gestarteten Sprint oder dem Entwicklungsstart für das nächste Release). Die notwendigen Zeitfenster sollten in der Projektplanung berücksichtigt werden. So bleibt Zeit, Probleme zu erkennen und auch zu lösen – Hektik entsteht gegen Sprintende meist auch so schon genug.

Testen, Testen, Testen… und das automatisiert. Wer die klassische Testpyramide in der Softwareentwicklung einhält, kann fast schon gefahrlos Updates einzelner Bibliotheken fahren. Wenn die Tests kritische Pfade ablaufen, Rand- wie auch Standardfälle beachten, einen gewissen Grad an Überdeckung erreichen und automatisiert in der Build-Pipeline ausgeführt werden, lassen sich Updates mit ruhigem Gewissen durchführen.

Versionen bewusst wählen – viele Bibliotheken bieten LTS (LongTimeSupport) Versionen an. Dies stellt sicher, so lange wie möglich mit Sicherheitspatches versorgt zu werden, ohne Gefahr zu laufen, über Breaking Changes das Projekt und den Code anpassen zu müssen. Für Bestandteile im Projekt, die meist sehr stabil sind und an die selten neue Anforderungen gestellt werden, sollte man diese Versionen immer bevorzugen.

Kurz und knapp zusammengefasst:

Wer seine Updates umsichtig plant, das passende Tooling einsetzt und über eine gute Testabdeckung verfügt, kann sein Projekt einfach und ohne Risiko aktuell halten und sollte dies auch tun. Klar, trotz all dieser Maßnahmen kann bei Updates immer noch etwas schiefgehen. Aber bestenfalls erkennt man dies direkt und zu einem Zeitpunkt im Projekt, an dem man gut reagieren kann.

.