Laravel-Anwendung übernehmen und weiterentwickeln

Laravel ist das Framework, mit dem ich seit Jahren die meisten individuellen Anwendungen baue: Produktions- und Logistik-Tools mit SAP-Anbindung, B2B-Plattformen, Schnittstellen. Übernommene Laravel-Anwendungen sind oft solide gebaut, aber seit Jahren nicht mehr aktualisiert worden.

Wann ist eine Laravel-Übernahme typisch?

• Der Entwickler, der die Anwendung gebaut hat, ist nicht mehr da, und die Anwendung läuft auf Laravel 8, 9 oder älter.
• Composer-Pakete blockieren das Update, weil sie nicht mehr gepflegt werden.
• Queues, Scheduler oder Horizon laufen irgendwo, aber niemand weiss genau, wie und wo.
• Das Frontend hängt an Laravel Mix, Webpack oder einer alten Vue.js-Version.

Worauf ich bei Laravel zuerst schaue

1. Versionen: Laravel, PHP und die wichtigsten Pakete. Welche Pakete bremsen ein Upgrade, welche sind verwaist?
2. Betrieb: Queue-Worker, Cronjobs, Horizon, Caches, Dateispeicher. Was muss laufen, damit die Anwendung funktioniert?
3. Konfiguration und Geheimnisse: .env, API-Schlüssel, Drittanbieter-Zugänge. Liegen sie irgendwo dokumentiert, oder nur auf dem Server?
4. Tests und Deployment: Gibt es Tests, eine Pipeline, eine Staging-Umgebung? Oder wird per FTP deployt?
5. Eigene Konstrukte: Überschriebene Framework-Klassen, Logik in Controllern, Datenbankzugriffe ausserhalb von Eloquent.

Upgrade über die Hauptversionen

Laravel veröffentlicht jährlich eine neue Hauptversion. Wer ein paar Jahre nichts macht, ist schnell drei oder vier Versionen im Rückstand. Das Upgrade gehe ich Version für Version an, zuerst mit Tests für die kritischen Abläufe, dann mit Rector und den offiziellen Upgrade-Guides. So bleibt die Anwendung nach jedem Schritt lauffähig und deploybar.