Laravel-Upgrades & Rettung

Zwei Situationen bringen die meisten Teams hierher. Entweder ist eine Anwendung weit genug zurückgefallen, dass ein Upgrade sich wie ein Projekt anfühlt statt wie eine Pflichtaufgabe, oder sie wurde von jemandem gebaut, der gegangen ist, und das heutige Team hat Angst, sie auszuliefern.

Beides ist lösbar. Keines erfordert üblicherweise einen Neubau.

Upgrades, eine Version nach der anderen

Über vier Hauptversionen gibt es keine Abkürzung. Der Weg sind die Versionen der Reihe nach, denn der Upgrade-Leitfaden jedes Releases setzt voraus, dass Sie aus dem vorigen kommen, und zu überspringen bedeutet, über Wechselwirkungen nachzudenken, die niemand dokumentiert hat.

Sicher wird es durch die Reihenfolge der Arbeit:

1. Abdeckung vor Bewegung. Charakterisierungstests über die Routen und die Jobs, die zählen – sie sichern zu, was die Anwendung heute tut, richtig oder falsch. Ohne das ist ein Upgrade eine Reihe von Änderungen ohne jede Möglichkeit festzustellen, ob sie etwas kaputtgemacht haben.
2. PHP neben Laravel. Die beiden Randbedingungen bewegen sich zusammen, und der Abhängigkeitsgraph entscheidet meist die Reihenfolge. Ein Paket ohne Release für Ihre Ziel-PHP-Version wird jetzt entdeckt und nicht drei Versionen später.
3. Eine Version pro Branch, zusammengeführt. Jeder Schritt für sich ausgeliefert, damit ein Rückfall einer Änderung zuzuordnen ist und nicht vierzig.
4. Abhängigkeiten geprüft statt hochgezogen. Ein aufgegebenes Paket ist eine Entscheidung – ersetzen, selbst übernehmen oder hinnehmen – und diese Entscheidung ist billiger, wenn sie bewusst getroffen wird, als wenn ein kaputter Build sie um Mitternacht trifft.

Am längsten dauert meist nicht das Framework. Es sind die Pakete drumherum, und zwar genau die, die irgendwo zwischen Ihrer Version und der aktuellen aufgegeben wurden.

Geerbte Codebasen

Die ersten zwei Wochen enthalten keine Commits. Sie erzeugen eine Abhängigkeitskarte, ein Verzeichnis jeder Route und jedes Jobs mit dem, worauf sie jeweils zugreifen, eine Liste des nachweislich toten Codes und ein Risikoregister, sortiert danach, was zuerst wehtun wird.

Dieses Dokument behalten Sie, wie die Entscheidung auch ausgeht. Mehr als ein Kunde hat es dem eigenen Team gegeben und es ohne uns abgearbeitet, was ein völlig gutes Ergebnis ist und uns lieber ist als ein widerwilliges Projekt.

Es ist das Risikoregister, das den Ton des Gesprächs ändert. Gegen „die Codebasis ist ein Chaos" lässt sich nicht planen – das ist eine Stimmung. Planen lässt sich gegen: Zahlungen haben keinen Test, zwei Jobs belasten bei einer Wiederholung doppelt, Queue-Fehler alarmieren niemanden, und drei Pakete tragen veröffentlichte Sicherheitshinweise ohne Upgrade-Pfad. Das ist ein Backlog, und ein Backlog wird der Reihe nach von dem abgearbeitet, der eine Woche frei hat.

Was wir fast jedes Mal finden

Geschäftsregeln in Controllern. Dieselbe Regel dreimal leicht unterschiedlich umgesetzt, sodass niemand sagen kann, was die Anwendung tatsächlich zusichert.

Eine .env, die die einzige Dokumentation der Infrastruktur ist. Dienste, die niemand benennen kann, Zugangsdaten, die niemand gewechselt hat, und mindestens ein Wert, der tragend und undokumentiert ist.

Jobs, die nicht gefahrlos wiederholbar sind. Was bisher gutging, weil die Queue still gescheitert ist statt zu wiederholen.

Eine Staging-Umgebung, die der Produktion nicht entspricht – in genau der Dimension, die zählt, meist dem Datenvolumen, gelegentlich der PHP-Version.

Was die Arbeit zusammenhält

Nichts bewegt sich ohne einen Test, der es merken würde. Das ist die ganze Methode. Abdeckung zuerst, Upgrade danach, und wo Abdeckung wirklich unpraktikabel ist, wird die Änderung kleiner und der Rückweg geprobt.

Jeder Schritt ist auslieferbar. Kein langlebiger Branch. Wenn sich Prioritäten ändern und die Arbeit ein Quartal lang ruht, ist das Zusammengeführte in sich stimmig und das Verbleibende eine Liste statt eines Konflikts.

Der Zielzustand ist aufgeschrieben. Ein Upgrade ohne festgehaltene Ziellinie wird binnen eines Personalwechsels zu einer Codebasis, in der niemand weiß, welche Konvention die aktuelle ist.

Wann ein Audit der bessere erste Schritt ist

Wenn Sie einen Verdacht haben statt einer Entscheidung – die Anwendung fühlt sich brüchig an oder ist teuer zu ändern, und niemand kann genau sagen warum – beantwortet ein Audit das in zwei Wochen und sagt Ihnen, ob ein Upgrade überhaupt die richtige Reaktion ist. Manchmal ist es das nicht: Die Version ist in Ordnung und das Problem sind vier Endpunkte und eine Queue, die niemand beobachtet – ein weit kleineres Stück Arbeit.

Wie es zugeschnitten wird

Wir lesen zuerst die Anwendung: die Version, die Pakete ohne gepflegte Alternative, was die Testabdeckung wirklich abdeckt und wie weit sich das Framework darunter bewegt hat.

Daraus entsteht ein schriftlicher Leistungsumfang mit den Versionsschritten, ihrer Reihenfolge und einem Preis. Geschätzt wird pro Schritt statt mit einer Zahl für die ganze Strecke, Sie können also nach jedem aufhören, haben eine lauffähige Anwendung und entscheiden dann, ob der nächste sich lohnt. Der Vertrag bezieht sich auf dieses Dokument.

Die Arbeit beginnt nach der Unterschrift. Ein Release nach dem anderen, jeder Schritt als eigener Pull Request.

Was Sie bekommen

Die Anwendung auf einer aktuellen Version, Release für Release bewegt, jeder Schritt als eigener Pull Request, damit die Änderung, die etwas kaputtgemacht hat, auch die ist, auf die Sie zeigen können. Daneben die Testabdeckung, die den Umzug abgesichert hat und die danach bleibt, meist die wertvollere Hälfte.

Sie bekommen außerdem die Liste dessen, was wir bewusst liegen gelassen haben: Pakete ohne gepflegte Alternative, Code, der funktioniert und noch nicht angefasst werden sollte, und was jedes davon kosten wird, wenn es doch so weit ist.