Mit neuen Versionen von Software ist das bekanntlich so eine Sache. Lohnt sich das Update? Und viel wichtiger: Geht nach dem Update noch alles? Lässt sich ein Fehler überhaupt so ohne weiteres finden, und wie leicht kann er danach behoben werden? Als ob das nicht bereits ausreichen würde, stellt sich oft auch die Frage, welche Kaskade an weiteren Updates und damit neuen, zusätzlichen Problemen das vermeintlich schnelle Update wohl nach sich zieht. Warum also den Aufwand und das Risiko eingehen, wenn doch gerade alles so schön funktioniert?
Einem Upgrade von Software lässt sich oft nur sehr schwer ein Mehr- bzw. Geschäftswert beimessen. Wie also den Product Owner überzeugen? Klar, Sicherheit ist, vor allem in Zeiten der DSGVO, wichtig, und so wird meist zähneknirschened Zeit zumindest für das Einspielen von notwendigen (Sicherheits-)Updates eingeräumt. Aber wo ist darüber hinaus der Mehrwert?
Um diese Fragen beantworten zu können, muss man erst einmal klären, was da überhaupt zu aktualisieren wäre. Handelt es sich beispielsweise um die neueste Version der Buchhaltungssoftware des Unternehmens, wird man, schon alleine der geänderten Gesetze wegen, kaum um das Update herumkommen. Wie sieht es aber aus, wenn es sich um eine Programmiersprache und deren Laufzeitumgebung handelt? Neue Sprachkonstrukte und verbesserte Funktionalitäten mögen zwar erfreulich für die Entwickler sein, machen aber die existierende Software nicht von selbst besser: Um von den Verbesserungen profitieren zu können, müsste man schließlich den Quelltext anpassen. Das kostet Zeit und somit Geld. Alles nur, damit die Software in der Aussenwahrnehmung das Gleiche kann wie vor der Anpassung?
Ein gutes Argument für ein Update von PHP ist die verbesserte Performance. Zwar war bisher so ziemlich jede neu erschienene Version von PHP schneller als ihr Vorgänger, bei PHP 7.0 war der Sprung aber besonders deutlich. Daher kann man auch ohne Änderungen am Quelltext von den Optimierungen profitieren.
Das PHP-Projekt ist, trotz massiver – und teils leider auch gerechtfertigter – Kritik an Inkonsistenzen der Sprache und Design-Entscheidungen der Vergangenheit, sehr auf Rückwärtskompatibilität bedacht. Die allermeiste Software, die für PHP 5.6 oder sogar früher entwickelt wurde, läuft daher ohne nennenswerte Änderungen auch mit PHP 7.
Natürlich bringt ein größerer Versionssprung auch fast unvermeidbar einige Inkompatibilitäten mit sich. Wie stark sich diese auf die eigene Codebasis auswirken, hängt allerdings – vielleicht wenig überraschend – stark mit der Größe des Sprungs zusammen. Sämtliche sogenannte Backwards Compatibility-Breaks, also Inkompatibilitäten zur Vorversion, werden bei PHP zum Teil über mehrere Versionen hinweg angekündigt, indem bestimmte Funktionalitäten als deprecated – „abgekündigt“ – markiert werden. Das ist ein Hinweis darauf, dass man sich von deren Verwendung distanzieren sollte, und es gibt keinen Grund dafür, damit bis zum Upgrade auf die nächste PHP-Version zu warten.
Wer nicht nur seine Software selbst weiter entwickelt, sondern auch die Umgebung, in der sie läuft, ständig aktuell hält, der braucht von Version zu Version immer nur kleine Änderungen vornehmen – wenn überhaupt. Eine solche mögliche Änderung ist das schrittweise Aktivieren der strengen Typprüfung mittels declare(strict_types=1);
. Es ist fast schon erschreckend, wie oft man auf kleine Ungenauigkeiten der eigenen Arbeit erst durch diese Änderung aufmerksam wird – und sich das eine oder andere Mal fragt, wieso die Software vorher überhaupt funktioniert hat.
Software dient schließlich in den seltensten Fällen einem Selbstzweck. Umso wichtiger sollte es einem Unternehmen daher sein, die von ihm getätigten Investitionen in die Entwicklung zu schützen. Dazu gehört es, neben der Anpassung an geänderte Geschäftsprozesse und ausreichende Tests, eben auch, die zur Ausführung notwendigen Komponenten wie Sprachversion, Bibliotheken und Werkzeuge aktuell zu halten.
Sollte man zumindest meinen. Denn sieht man sich die zuletzt Ende 2018 veröffentlichten Zugriffs-Statistiken von Packagist einmal genauer an, so stellt man erstaunt fest, dass gerade einmal knapp ein Drittel der PHP-Installationen, die auf Packagist zugreifen, von einer aktuellen und vom PHP-Projekt voll unterstützten Version erfolgen. Einem Drittel! Kleiner Lichtblick: Der Anteil von PHP 5.x ist seit Mai 2018 auf 15% gesunken und wird hoffentlich bald ganz entfallen.
Doch warum arbeitet ein so großer Anteil der Benutzer nicht mit einer aktuellen PHP-Version? Eine mögliche Erklärung wäre, dass viele der Packagist-Zugriffe von einmal aufgesetzten durchgängig automatisierten Systemen erfolgen, die ständig die gleichen Versionen der Software herunterladen und so die Statistik verzerren. Allerdings würde dieses Problem vermutlich auf beide Seiten, alte wie neue Versionen, zutreffen und sollte daher die Zahlen nicht allzu sehr verfälschen.
Bei einem weiteren Teil könnte es sich um einfach vergessene Systeme handeln, die stoisch weiter ihre Arbeit verrichten, selbst wenn sich für das Ergebnis längst niemand (mehr) interessiert. Klingt unrealistisch? Leider nein, wie man an den Installationsversuchen von PHPUnit sehen kann: Neben selbstverständlich vielen Downloads via Composer und der PHAR-Archive, wird auch fleissig weiter via PEAR-Installer installiert. Freilich, seit Ende 2014 – und damit immerhin seit gut 4 Jahren – kann via PEAR keine Version von PHPUnit mehr installiert werden. Das scheint aber nicht sonderlich zu stören, denn bis heute greifen täglich viele Systeme auf den abgeschalteten Server pear.phpunit.de
zu.
Dass PHPUnit hier nicht alleine steht, belegt das PEAR-Projekt, das gerade wieder aus dem Dornröschenschlaf erwacht, weil der offizielle pear.php.net Server gehackt wurde . Anstatt den PEAR-Installer mitsamt der dazugehörigen Infrastruktur, die dank Composer nicht mehr benötigt wird, in den wohl verdienten Ruhestand zu schicken, hatten unbekannte Angreifer den PEAR-Server übernommen und verbreiteten Schadsoftware. Womöglich über Monate hinweg unerkannt wurde eine durch die Angreifer manipulierte Version des CLI-Werkzeugs bereitgestellt. Glücklicherweise sind die Server jetzt erst einmal offline. Ob sie je wieder aktiviert werden, wird sich zeigen und vermutlich nicht zuletzt von den Reaktionen der User abhängen, die die PEAR-Server vermissen – oder eben vielleicht, hoffentlich!, auch nicht.
Sonderlich neu und aktuell dürften die meisten verfügbaren Pakete indes eh nicht mehr sein, viele extern gehosteten Abhängigkeiten wie eben PHPUnit fehlen bereits seit längerer Zeit. Allerdings sieht es auch auf Packagist nicht unbedingt rosig aus: Obwohl große Projekte wie Symfony, Laravel oder NEOS und auch bekannte Werkzeuge wie PHPUnit, PhpSpec und Xdebug in aktuellen Fassungen jeweils mindestens PHP 7 voraussetzen, unterstützten im November 2018 fast 80% der gelisteten Projekte mit ihrer jeweils aktuellsten Version veraltete PHP-Versionen als Mindestanforderung. Auch auf Packagist ist PHP 5 noch immer lebendig: Beinahe 60% der verfügbaren Pakete unterstützen diese Version.
Die Kompatibilität auch mit älteren PHP-Versionen ist dabei natürlich nicht per se schlecht. Ob es sich allerdings lohnt, auch bei neuen Releases auf Versionen Rücksicht zu nehmen, die – zum Teil seit Jahren – keinerlei offiziellen Support mehr bekommen, dürfte zumindest fraglich sein. Selbst das mit dem offiziellen Support ist leider nicht ganz so einfach zu beurteilen, wie es scheinen mag. Denn sowohl Debian Linux als auch die meisten anderen großen Linux-Distributionen bieten mit ihren jeweiligen LTS-Versionen auf Jahre hinaus Unterstützung für längst abgekündigte Versionen von PHP und andere Komponenten an. Ein Wechsel auf eine neuere Version ist zwar zumeist technisch möglich, jedoch im Enterprise-Umfeld aus juristischen Gründen häufig gar nicht gewünscht.
In einer Welt, in der immer mehr Software in Containern ausgeführt wird, sollte der Bedarf an LTS-Versionen eigentlich drastisch abnehmen. Denn wer es gewohnt ist, für ein Deployment automatisiert ein neues Image zu erstellen, der hat keinen Grund mehr dafür, mit der Laufzeitumgebung veraltete Software auszurollen. Ganz im Gegenteil: Auch und gerade diese Systeme auf einem aktuellen Stand zu halten sollte klares Ziel eines jeden Teams sein, das DevOps verstanden hat.
Die Erkenntnis, dass jegliche Software gewartet werden möchte, ist beileibe nicht neu. Interessanterweise werden die Folgen der Vernachlässigung in der Software-Entwicklung genauso oft ignoriert, wie es in anderen Bereichen des Alltags der Fall ist. Nicht von ungefähr kämpft die Menschheit fast überall auf der Welt mit einer maroden und kaputt gesparten Infrastruktur. Noch hält die Brücke ja ...