Wann ist der richtige Zeitpunkt für ein Software-Upgrade?

Eine neue Softwareversion ist immer ein spannendes Ereignis, sie kann einem alten Hund neue Tricks beibringen und ihn möglicherweise auf denselben alten Beinen schneller laufen lassen als zuvor. Das ist die Magie von Software, die scheinbar aus dem Nichts neue Funktionen mit sich bringt. Während es einfach ist, seinen geliebten Aibo mit dem neuesten Software-Update zu pflegen, ist es vielleicht nicht so einfach, ein ganzes Rudel von Hunden auf den neuesten Stand zu bringen. Unterschiedliches Alter, Modelle, Versionen... Es kann kompliziert werden.

Abgesehen von den Roboterhunden ist die Situation für nahezu jede Software die gleiche. In einem einfachen Szenario kann ein größeres Upgrade eine eintönige Aktion sein; Sagen wir, man aktualisiert sein Freizeitprojekt 15 Minuten nach dem Start auf die neueste Hauptversion, nimmt sich weitere 15 Minuten Zeit, um einen kurzen Text darüber zu verfassen, wie einfach das Upgrade war, postet ihn auf Hacker News und lässt das Publikum über sein Leben im siebten Himmel des Bleeding Edge staunen.

Heutzutage bewegt sich die Software-Industrie in einem anstrengenden Tempo. Der kontinuierliche Fluss von Updates, die für Frameworks und Bibliotheken bereitgestellt werden, geht Tag und Nacht weiter. Jeden Tag gibt es eine neue Aussicht auf ein Upgrade, ob umfangreich oder minimal. Dies ist auch Teil der Verlockung der allgegenwärtigen Microservices-Architektur, bei der Systeme aus kleinen unabhängigen und entkoppelten Softwareteilen aufgebaut werden.

Kein Microservice ist eine Insel

In Wirklichkeit ist ein Microservice aber nicht zu 100 % von der Umgebung isoliert. Es wird eine Vielzahl von gemeinsam genutztem Code verwendet. Bis alle Teile mit der neuesten Basis-Software-Version kompatibel sind, kann es dauern. Wenn man beispielsweise Node.js verwendet, ist es wahrscheinlich, dass es Tausende von Abhängigkeiten im NPM-Katalog gibt. Man kann in 15 Minuten einsatzbereit sein, jedoch ist es unwahrscheinlich, dass das gesamte Ökosystem verfügbar ist.

Bei Plattformen wie Go oder Deno, die über eine umfangreichere Standardbibliothek verfügen, ist das Einpflegen von Abhängigkeiten einfacher, aber trotzdem muss man für eine neue Hauptversion möglicherweise die eigene Codebasis ein wenig anpassen. Das hängt von den Änderungen der Rückwärtskompatibilität ab, davon, wie konservativ die Projektleitung ist, und letztlich von purem Glück. 🍀

Offensichtlich gibt es keinen einheitlichen Zeitplan, wann man auf eine neue Version aktualisieren sollte. In Fällen, in denen man nur wenige Abhängigkeiten hat, und die Vorteile (oft verbesserte Leistung) so deutlich sind, könnte man sich für ein Upgrade innerhalb von Tagen oder Wochen nach der Einführung entscheiden. Vor allem, wenn man sich schon im Vorfeld vorbereitet hat, indem man mit Betas und Release Candidates gearbeitet hat, wie Arnold Palmer es ausdrückte: Je mehr ich übe, desto mehr Glück habe ich.

Beispiel Ibexa DXP und PHP 8.0

Bei Ibexa DXP ist die Grundlage der Backend-Technologie das Symfony-Framework, das wiederum auf PHP läuft. Für beide gibt es neue Versionen, die Ende 2020 erschienen sind. Das Symfony-Framework wird eine neue Version 5.2 erhalten. Gemäß der semantischen Versionierung handelt es sich dabei um eine Minor-Version, die mit dem aktuellen Symfony-Release 5.1, das in Ibexa DXP 3.2 verwendet wird, kompatibel sein wird. Das Upgrade ist für Ibexa DXP 3.3 LTS geplant, das Anfang 2021 erscheinen soll.

Bei PHP 8.0 ist die Sache schon etwas komplizierter. Die neue Version bietet einige interessante neue Language Features und erhöhtes Performance-Potenzial mit einigen Vorbehalten:

In Bezug auf die Leistung scheint JIT hier [für PHP 8.0] eine durchmischte Angelegenheit zu sein. Es verlangsamt sich bei geringer Nebenläufigkeit und bietet eine signifikante Verbesserung des Durchsatzes verglichen mit nur OPCache Preloading. Weitere Nachforschungen sind nötig. Hier ist die Sachlage nicht eindeutig, da es die Leistung beeinträchtigen könnte. JIT scheint etwas zu sein, das von Fall zu Fall für PHP betrachtet werden sollte.
- PHP 8.0 und 7.4 Benchmarks auf Symfony 5.2

Damit wir Ibexa DXP für die Nutzung von PHP 8.0 aufrüsten können, müssen wir sicherstellen, dass unsere Software mit dieser Version kompatibel ist und dass das PHP-Ökosystem (einschließlich Symfony und einer Reihe anderer Bibliotheken) ebenfalls mit dieser Version funktioniert. Wenn dies gewährleistet ist, können wir eine technische Kompatibilität mit PHP 8.x erreichen. Noch ist nichts entschieden, aber wir könnten möglicherweise inoffizielle Unterstützung für PHP 8 in Ibexa DXP 4.0 hinzufügen. Das bedeutet nicht, dass man Ibexa DXP technisch nicht mit PHP 8.0 vor 4.x betreiben könnte. Um jedoch Support für unsere Software anbieten zu können, müssen wir die Kompatibilität garantieren.

Vorwärtskompatibilität ist eine Sache, aber Rückwärtskompatibilität ist der Punkt, an dem es schwieriger wird. Als Software-Ingenieure möchte unser Team Zugriff auf die neuesten Language Features haben. Gleichzeitig müssen wir aber auch darauf achten, dass unsere Software in so vielen Umgebungen wie möglich einsetzbar ist. Da Ibexa DXP eine Entwicklungsplattform ist, können wir PHP 8.0 nicht zur Voraussetzung machen, bevor es alltäglich ist.

Während uns also die Hände gebunden sind, einige der neuen Funktionen in 8.0 zu nutzen, schränkt es unsere Partner und Kunden nicht ein, es ab dem Tag der offiziellen Unterstützung zu nutzen. Implementierungsprojekten steht es frei, die neueste Syntax und andere Funktionen zu nutzen, da das Eigentum an diesem Code den Integratoren gehört, die auf der Ibexa DXP-Technologie aufbauen.

Fazit

Eine Entscheidung über ein Upgrade ist eine Abwägung. Ist das Upgrade das Risiko wert, oder sollten Sie dem Prinzip Wenn es nicht kaputt ist, repariere es nicht folgen. Würde man z. B. bei einem Roboter-Windhund ein Upgrade durchführen, das ihn um 9 % schneller macht, ihn aber auch bei Vollmond in einen Höllenhund verwandeln könnte? Das ist kein realistisches Szenario, aber ein Unternehmen kann durch ein verpfuschtes Software-Upgrade ernsthaften Schaden erleiden.

Für Software-Anbieter ist dies sogar noch schwieriger. Es ist möglich, sich vorwärts zu bewegen und technische Altlasten zu beseitigen und gleichzeitig die Rückwärtskompatibilität zu wahren. Allerdings ist dies mit sehr viel mehr Arbeit verbunden und erfordert eher langfristige Überlegungen als schnelle Erfolge. Der Schlüssel dazu ist die kontinuierliche Evaluierung und das Verfolgen der Markttrends. Aktuelle und gut gewartete Software ist nicht nur relevanter für Unternehmen, sondern auch attraktiver für Entwickler. Aus diesem Grund beschäftigen wir uns bei Ibexa schon jetzt mit kommenden Technologien und sprechen darüber, auch wenn noch keine offizielle Unterstützung dafür besteht.

Unabhängig davon, ob man Endanwender oder Anbieter von Software ist, sollte man zumindest die folgenden Dinge berücksichtigen, bevor man ein Software-Upgrade aus der Perspektive der jeweiligen Version vornimmt - kurz-, mittel- und langfristig:

• Bereitschaft der Codebase?
• Reifegrad des Ökosystems?
• Welchen Nutzen hätte man davon?
• Welche Risiken gibt es?
• Muss ein Rollback möglich sein? Kann es durchgeführt werden?
• Ist der Zeitpunkt für das Update geeignet?
• Bestehen die nötigen Ressourcen für das Update?
• Wird durch die Verzögerung nur die technische Last verschoben?

Manchmal ist es die richtige Entscheidung, gleich ein Upgrade durchzuführen, um die Anwendung auf dem neuesten Stand zu halten, denn der Sprung über mehrere Hauptversionen kann mehr Arbeit bedeuten als ein Upgrade nach dem anderen. Eine weitere Option ist, die Anwendung nicht zu aktualisieren. Wenn das Auslaufen der Software geplant ist, sollte man nur wichtige Updates durchführen und die Zeit und den Aufwand anderweitig investieren. Die Lebensdauer einer Codebasis ist begrenzt; manchmal ist dies durch das Design oder die Umstände bedingt, aber häufiger durch das Fehlen einer regelmäßigen Wartung.

Bei Ibexa bauen wir zukunftssichere Software und behalten dabei die Rückwärtskompatibilität im Auge.