Die PHP-Kolumne: Zeit für PHP

Das Problem mit veralteten Versionen: Updates kosten doch nur Geld?
Keine Kommentare

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? Diese und weitere Fragen stellen sich, wenn eine neue Version im Raum steht. Warum sollte man 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ähneknirschend 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 allein 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 Außenwahrnehmung das Gleiche kann wie vor der Anpassung?

Software ist in den seltensten Fällen Selbstzweck

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, doch bei PHP 7.0 war der Sprung besonders deutlich. Daher kann man auch ohne Änderungen am Quelltext von den Optimierungen profitieren. Das PHP-Projekt ist, trotz massiver – und leider teils auch gerechtfertigter – Kritik an Inkonsistenzen der Sprache und Designentscheidungen 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.

International PHP Conference

Entwickler – das verlorene Handbuch

by Stefan Priebsch (thePHP.cc)

My browser does what?

by Joel Lord (Red Hat OpenShift

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 so genannte 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 (unerwünscht) 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 weiterentwickelt, sondern auch die Umgebung, in der sie läuft, ständig aktuell hält, der muss 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 ist schließlich in den seltensten Fällen 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 Zugriffsstatistiken von Packagist einmal genauer an, 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ützen 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.

Vergessene Systeme, veraltete Versionen

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.

„Ein größerer Versionssprung bringt fast unvermeidbar Inkompatibilitäten mit sich.“

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 PHAR-Archive wird auch fleißig weiter via PEAR-Installer installiert. Freilich, seit Ende 2014 – und damit immerhin seit gut vier 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 allein 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 dazu gehörigen Infrastruktur, die dank Composer nicht mehr benötigt wird, in den wohlverdienten 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 ohnehin 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 Erkenntnis, dass jegliche Software gewartet werden möchte, ist nicht neu.“

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.

Die Folgen der Vernachlässigung

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, 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 Softwareentwicklung genauso oft ignoriert, wie es in anderen Bereichen der Fall ist. Nicht von ungefähr kämpft die Menschheit fast überall auf der Welt mit einer maroden und kaputtgesparten Infrastruktur. Noch hält die Brücke ja …

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -