Hinweis

Die folgenden Szenarien beschreiben wiederkehrende Muster aus unserer Arbeit, keine einzelnen Kundenprojekte. Gemessene Zahlen nennen wir dazu bewusst nicht, weil sich Laufzeiten und Aufwände je nach Projekt stark unterscheiden. Was Ihr Projekt braucht, sagen wir Ihnen nach der Analyse.

PHP 5.6 → 8.3 Symfony 2.8 → 6.4 Shop

Szenario: gewachsener Onlineshop

Ein Shop, der über Jahre erweitert wurde: viele eigene Bundles, direkte Datenbankzugriffe quer durch den Code, keine Tests.

ausgangslage
PHP 5.6 (EOL seit 2018)
Symfony 2.8 (EOL seit 2019)
keine automatisierten Tests
Deployment per FTP
offene Lücken in Abhängigkeiten
danach
PHP 8.3 (active support)
Symfony 6.4 LTS
Tests für die kritischen Pfade
Deployment über CI-Pipeline
Abhängigkeiten auf aktuellem Stand
Schwierigkeit

Legacy-Abhängigkeiten

Eigene Bundles mit direkten SQL-Abfragen, globaler Zustand, keine Dependency Injection. Dazu ein Payment-SDK, das es nur für PHP 5 gibt.

Weg

Schrittweise statt am Stück

Erst 7.4 als Zwischenstand, dann 8.3. Das Symfony-Upgrade läuft parallel über die LTS-Versionen. Das Payment-SDK wird durch einen aktuellen API-Client ersetzt.

Ergebnis

Wieder anschlussfähig

Der Shop läuft auf einer unterstützten Version, lässt sich wieder mit aktuellen Bibliotheken erweitern, und Änderungen sind durch Tests abgesichert.


PHP 7.2 → 8.2 Symfony 3.4 → 6.3 Plattform

Szenario: Plattform mit Queue-System

Eine Anwendung mit Hintergrundverarbeitung, bei der die Worker unter Last aussteigen und niemand mitbekommt, wann das passiert.

ausgangslage
PHP 7.2 (EOL seit 2020)
Symfony 3.4 (EOL seit 2021)
keine reproduzierbare Umgebung
Worker fallen unter Last aus
kein Monitoring
danach
PHP 8.2 (active support)
Symfony 6.3 mit Messenger
Docker für alle Umgebungen
Worker mit Wiederanlauf
Monitoring aktiv
Schwierigkeit

Ausfälle ohne Alarm

Hintergrundjobs sterben still. Gemerkt wird das erst, wenn Kunden nachfragen, warum etwas nicht angekommen ist.

Weg

Queue auf Symfony Messenger

Eigenbau-Queue durch Symfony Messenger ersetzen, die Umgebung in Docker abbilden, damit lokal und produktiv dasselbe läuft, und Monitoring aufsetzen.

Ergebnis

Fehler werden sichtbar

Fehlgeschlagene Nachrichten landen nachvollziehbar in einer eigenen Queue, statt verloren zu gehen. Ausfälle melden sich selbst.


PHP 7.4 → 8.4 Symfony 4.4 → 7.1 Auswertung

Szenario: rechenintensive Auswertung

Nächtliche Jobs, die große Datenmengen zusammenfassen und dabei ans Speicherlimit stoßen.

Schwierigkeit

Speicher und Laufzeit

Die Batch-Läufe erreichen regelmäßig das Speicherlimit. Abgebrochene Läufe muss jemand von Hand neu starten, meist am nächsten Morgen.

Weg

Aktuelle Laufzeit nutzen

Neuere PHP-Versionen gehen sparsamer mit Speicher um und bringen Werkzeuge mit, die es in 7.4 noch nicht gab. Dazu wird die Verarbeitung in Teilmengen zerlegt und die Cache-Strategie überarbeitet.

Ergebnis

Läufe gehen durch

Die Auswertung läuft ohne manuelles Nachfassen. Wie viel schneller sie wird, hängt vom konkreten Code ab, deshalb steht hier keine Zahl.


Womit wir arbeiten

Die Werkzeuge, die bei Migrationen und im laufenden Betrieb zum Einsatz kommen.

runtime
PHP 8.x
framework
Symfony 7
framework
Laravel
database
Doctrine ORM
testing
PHPUnit
quality
PHPStan
refactoring
Rector
infra
Docker
ci/cd
GitLab CI
messaging
RabbitMQ
cache
Redis
database
MariaDB

Ähnliche Ausgangslage?

Wir sehen uns Ihr Projekt an und sagen Ihnen, welcher Weg passt. Die Ersteinschätzung ist kostenlos.

Ersteinschätzung anfragen