Was drei Laravel-Versionen Rückstand kosten

Eine Anwendung, die drei Hauptversionen zurückliegt, ist nicht durch eine Entscheidung dorthin gelangt. Es gab ein Quartal, in dem ein Upgrade nicht hineinpasste, dann ein Release, bei dem ein Paket noch nicht nachgezogen hatte, dann ein Jahr, in dem nichts kaputtging – und die Sache mit einem Framework, das aus dem Support fällt, ist, dass an dem Tag nichts kaputtgeht.

Die Kosten sind trotzdem real. Sie sind nur aufgeschoben, und sie wachsen überproportional.

Die Rechnung, aufgeschlüsselt

Sicherheitsfixes hören auf zu kommen. Das ist der Teil mit einem Datum. Jedes Laravel-Release bekommt etwa zwei Jahre Sicherheitsfixes; verpassen Sie dieses Fenster, hat eine offengelegte Schwachstelle im Framework keinen Patch, den Sie einspielen können. Der Fix existiert – in einer Version, die Ihre Anwendung nicht installieren kann.

Ihre Abhängigkeiten gehen ohne Sie weiter. Pakete folgen dem Framework. Ein Jahr zurück heißt, eine oder zwei Versionen festzunageln. Drei Jahre zurück hat das Paket, das Sie brauchen, die Unterstützung für Ihre Einschränkung ganz fallengelassen, und etwas Neues zu installieren heißt, einen Graphen aufzulösen, der keine Lösung hat. Composer teilt Ihnen das auf die am wenigsten hilfreiche verfügbare Weise mit.

PHP fällt darunter aus dem Support. Laravel-Versionen tragen PHP-Anforderungen, und älteres PHP hört nach eigenem Zeitplan auf, Sicherheitsfixes zu bekommen. Jetzt müssen Sprache, Framework und Pakete alle bewegt werden, und zwar in einer bestimmten Reihenfolge.

Einstellen wird schwerer und Einarbeiten langsamer. Eine Entwicklerin, die seit drei Jahren mit Laravel arbeitet, hat die Konventionen Ihrer Version nie gesehen. Jede Dokumentation, die sie findet, beschreibt etwas anderes. Das stärkste Argument des Frameworks – dass jeder Laravel-Entwickler jede Laravel-Codebasis lesen kann – gilt für Ihre nicht mehr.

Die Arbeit selbst wird langsamer. Nicht weil die alte Version langsam ist, sondern weil alles ein Workaround ist. Funktionen, die in aktuellem Laravel eine Zeile sind, sind ein Paket, ein Trait oder vierhundert Zeilen, die jemand 2019 geschrieben und dann verlassen hat.

Warum es schlimmer wird statt gleich zu bleiben

Ein Upgrade von einer Version auf die nächste ist überwiegend mechanisch. Die brechenden Änderungen sind dokumentiert, es sind meist wenige, und die Release Notes sagen, worauf zu achten ist.

Drei Versionen sind nicht das Dreifache davon, aus zwei Gründen.

Die Änderungen greifen ineinander. Eine Verwerfung, die in einem Release eingeführt und zwei später entfernt wird, ist in den einzelnen Upgrade-Anleitungen unsichtbar und unvermeidlich, wenn man sie zusammen macht. Und man kann nicht sauber durchsteigen, weil die Pakete, die einen durch die Zwischenversionen getragen hätten, keine Versionen mehr haben, die beide Enden erfüllen.

Die Arbeit hört also auf, die Anleitung anwenden zu sein, und wird zu verstehen, was diese Anwendung eigentlich tut – was genau deshalb teuer ist, weil es derzeit niemand tut.

Wie es richtig aussieht

Lesen vor Schreiben. Was die Anwendung tut, welche Teile Tests haben, welche Abhängigkeiten aufgegeben wurden, welches PHP sie braucht. Daraus entsteht ein Dokument und eine Reihenfolge, und das ist der Teil, den man überspringen möchte.

Zuerst ein Sicherheitsnetz. Ein Upgrade ohne Tests ist ein Neubau mit Zwischenschritten. Feature-Tests über die Routen, die Geld tragen, und die Jobs, die andere Systeme berühren, reichen meist – keine vollständige Abdeckung, die mehr kostet als das Upgrade.

Die Sprache zuerst, wo es sie betrifft. Muss PHP sich bewegen, bewegt es sich vor dem Framework, weil das Framework nicht kann.

Eine Version nach der anderen, jeweils zusammengeführt. Upgraden, beheben, ausliefern, wiederholen. Jeder Schritt ist klein genug, um ihn zu durchdenken und zurückzurollen. Ein einzelner Branch, der alle drei versucht, endet als Merge-Konflikt mit einer Deadline daran.

Unterwegs löschen. Drei Versionen angesammelter Workarounds enthalten einige, die nur existieren, weil das Framework es damals nicht konnte. Heute kann es das. Diese Löschungen sind der Teil der Arbeit, der sich doppelt bezahlt macht.

Die Zahl, die man kennen sollte

Die ehrliche Fassung der Rechnung: Ein jährliches Upgrade ist eine kleine, vorhersehbare Ausgabe. Drei Jahre liegen gelassen, kostet dieselbe Arbeit ein Mehrfaches – nicht weil sich der Code stärker geändert hat, sondern weil das Wissen darüber, was die Anwendung tut, erst wieder aufgebaut werden muss, bevor irgendetwas sicher bewegt werden kann.

Und das Aufsummieren hört nicht auf, während Sie entscheiden. Ein weiteres Jahr bringt eine weitere Version, eine weitere Gruppe aufgegebener Abhängigkeiten und eine weitere Gruppe von Leuten, die das Unternehmen verlassen haben, seit irgendjemand das Zahlungsmodul verstand.

Wenn Sie das hier lesen, weil Sie bereits wissen, dass Sie zurückliegen, ist der nützliche erste Schritt kein Angebot. Es ist herauszufinden, wie weit genau, in welcher Reihenfolge sich was bewegen muss, und welche Teile der Anwendung derzeit niemand erklären kann – denn diese letzte Liste ist das, woraus der Preis tatsächlich besteht.

Die Anwendung zu lesen ist ein Audit. Sie zu bewegen ist Upgrade und Rettung. Ist sie einmal aktuell, ist Aktuellbleiben eine kleine monatliche Aufgabe, und das ist das ganze Argument für eine Wartungsvereinbarung.

Läuft die Anwendung gar nicht auf Laravel, laufen dieselben Zinsen auf dem Framework auf, auf dem sie läuft. Wir holen solche Anwendungen schrittweise herüber. Wir schreiben sie nicht neu.