Symfony-Updates planbar machen: Komponenten und Major-Versionen aktuell halten

Andreas Kunisch, , 5 Min. Lesezeit

Ein Symfony-Projekt, das zwei oder drei Major-Versionen hinter dem aktuellen Stand liegt, lässt sich nicht mehr in einem Schritt aktualisieren. Jede übersprungene Version bedeutet mehr Deprecations, mehr inkompatible Bundles und ein größeres Risiko beim nächsten Versuch.

Dabei lässt sich der Prozess planen. Symfony legt seinen Release-Zyklus offen, markiert unterstützte Versionen eindeutig und kündigt Breaking Changes lange vorher als Deprecation an. Wer diesen Rhythmus kennt und regelmäßig in kleinen Schritten aktualisiert, hält den Aufwand pro Update klein und den Betrieb stabil.

Wie oft erscheinen neue Symfony-Versionen und was bedeutet LTS?

Symfony veröffentlicht alle sechs Monate eine neue Minor-Version und alle zwei Jahre eine neue Major-Version. Innerhalb eines Major-Zweigs, etwa 6.0 bis 6.4, kommen mit jeder Minor-Version neue Funktionen hinzu, aber keine Breaking Changes: Veraltete APIs werden stattdessen als deprecated markiert und erst mit dem nächsten Major-Release entfernt.

Die letzte Minor-Version vor einem Major-Wechsel, zum Beispiel 5.4 vor 6.0 oder 6.4 vor 7.0, erhält den Status Long-Term Support (LTS). Reguläre Minor-Versionen werden einige Monate mit Bugfixes und etwas länger mit Sicherheitsupdates versorgt; eine LTS-Version bekommt beides über mehrere Jahre. Außerdem enthält eine LTS-Version denselben Funktionsumfang wie die folgende Major-Version, nur ohne deren Breaking Changes. Wer auf einer LTS-Version alle Deprecations behebt, kann meist mit einem reinen Versionssprung auf die neue Major-Version wechseln.

Wie löst man Deprecations rechtzeitig auf?

Deprecations behebt man am besten gleich, wenn sie auftauchen. Symfony markiert veraltete APIs frühzeitig mit Deprecation-Warnungen, lange bevor sie entfernt werden.

Diese Warnungen lassen sich im Log oder über den Symfony-Profiler einsehen; die PHPUnit-Bridge von Symfony sammelt sie zusätzlich während der Testläufe und listet sie gesammelt auf. Wer nach jedem Minor-Update kurz die Deprecation-Liste durchgeht und die betroffenen Stellen anpasst, hat beim nächsten Major-Update nichts mehr offen. Wer stattdessen über Jahre nicht aktualisiert, muss Hunderte Deprecations auf einmal auflösen, mit entsprechend höherem Risiko und Testaufwand.

Welche Rolle spielt Composer bei der Versionspflege?

Composer steuert, welche Versionen von Symfony-Komponenten und Abhängigkeiten ein Projekt überhaupt zulässt. Zu enge Versions-Constraints in der composer.json verhindern Updates, zu weite öffnen die Tür für ungeplante Breaking Changes.

Sinnvoll ist, Versionen eng genug zu binden, um Überraschungen zu vermeiden, aber regelmäßig mit composer outdated zu prüfen, welche Pakete hinter dem Stand liegen. Die composer.lock-Datei hält fest, welche Version aktuell installiert ist; Updates sollten in einem eigenen Branch erfolgen, damit sich das Ergebnis vor dem Merge testen lässt. Symfony Flex ergänzt beim Update automatisch neue Konfigurationsdateien für Recipes, was Handarbeit reduziert. Die generierten Änderungen sollte man trotzdem gegen die eigene Konfiguration prüfen.

Wie behält man Bundles von Drittanbietern im Blick?

Bundles von Drittanbietern bestimmen oft, wie schnell ein Projekt überhaupt aktualisieren kann. Jedes eingebundene Bundle muss die neue Symfony-Version unterstützen, sonst blockiert es das Update für das gesamte Projekt.

Vor einem geplanten Upgrade lohnt sich ein Blick in die Kompatibilitätsangaben und die Aktivität im jeweiligen Repository: Wird das Bundle noch gepflegt, gibt es offene Pull Requests für die neue Version, reagiert der Maintainer auf Issues? Bundles, die seit Jahren nicht mehr aktualisiert wurden, sind ein Risiko. Hier lohnt es sich, frühzeitig nach Alternativen zu suchen oder den benötigten Funktionsumfang notfalls selbst nachzubauen. Dann gibt es kurz vor einem Update keine Überraschung.

Welche Tests sichern ein Symfony-Update ab?

Ein belastbares Update braucht eine automatisierte Testsuite, die vor und nach jedem Schritt grün ist. Unit- und Funktionstests fangen die meisten Regressionen ab, bevor sie in Produktion auffallen.

Statische Analyse, etwa mit PHPStan, findet zusätzlich Typkonflikte und falsche Methodenaufrufe, die durch geänderte Signaturen entstehen. Ergänzend lohnt sich ein Testlauf mit aktivierter Deprecation-Erkennung, um neue Warnungen direkt nach dem Update zu sehen. Vor dem Rollout in die Produktion gehört außerdem ein manueller Test der kritischsten Abläufe auf einer Staging-Umgebung dazu, denn automatisierte Tests allein decken selten jeden Sonderfall ab.

Warum sollte man jede Minor-Version einzeln durchlaufen?

Wer jede Minor-Version einzeln durchläuft, behebt Deprecations in kleinen, überschaubaren Schritten statt in einem riskanten Großprojekt. Symfony erlaubt zwar technisch, mehrere Minor-Versionen auf einmal zu überspringen, solange Composer die Constraints zulässt.

In der Praxis sammeln sich dabei aber Deprecations, Konfigurationsänderungen und Verhaltensänderungen an, die sich nur schwer einzeln zuordnen lassen, wenn etwas kaputtgeht. Besser ist, nach jeder neuen Minor-Version zeitnah zu aktualisieren, die Deprecation-Liste zu prüfen und die Tests laufen zu lassen. Dieser Rhythmus, alle sechs Monate ein kleiner Schritt, verteilt den Aufwand gleichmäßig und verhindert, dass sich über Jahre ein Rückstand aufbaut, der sich irgendwann nur noch mit einem großen, riskanten Sprung aufholen lässt.

Wie rollt man ein Update im Betrieb aus, ohne ihn zu gefährden?

Ein Update gehört in kleinen, einzeln überprüfbaren Schritten in die Produktion. Abhängigkeits- und Versionsupdates sollten getrennt von fachlichen Änderungen laufen, damit sich ein auftretender Fehler eindeutig zuordnen lässt.

Bei einer Reise-Buchungsplattform, die ich über mehrere Jahre technisch mitbetreut habe, liefen Komponenten-Updates genau so ab: in kleinen Schritten während des laufenden Betriebs, getestet und mit der Möglichkeit, jederzeit zurückzurollen.

  1. Update in einem separaten Branch vorbereiten und automatisiert testen.
  2. Auf einer Staging-Umgebung mit produktionsnahen Daten überprüfen.
  3. Rollback-Plan festlegen, bevor der Schritt live geht.
  4. Einen Schritt zur Zeit ausrollen und Monitoring aktiv beobachten.
  5. Erst nach stabilem Betrieb den nächsten Schritt vorbereiten.

Häufige Fragen

Wie oft sollte man ein Symfony-Projekt aktualisieren?
Im Idealfall nach jeder neuen Minor-Version, also etwa alle sechs Monate. Das hält die Deprecation-Liste kurz und den Aufwand pro Update gering. Wer diesen Rhythmus verpasst, sollte spätestens beim Erscheinen der nächsten LTS-Version nachziehen.
Was ist der Unterschied zwischen einem Minor- und einem Major-Update?
Ein Minor-Update, etwa von 6.3 auf 6.4, fügt neue Funktionen hinzu und markiert veraltete APIs als deprecated, entfernt aber nichts. Ein Major-Update, etwa von 6.4 auf 7.0, entfernt genau diese als deprecated markierten APIs. Wer vor dem Major-Update alle Deprecations behoben hat, besteht diesen Schritt meist ohne nennenswerte Codeänderungen.
Lohnt es sich, auf einer LTS-Version zu bleiben?
Ja, eine LTS-Version ist ein guter Ruhepunkt, um Deprecations in Ruhe aufzuarbeiten, da sie länger mit Bugfixes und Sicherheitsupdates versorgt wird als reguläre Minor-Versionen. Dauerhaft sollte man aber auch von einer LTS-Version irgendwann weiterziehen, da sonst neue Features und spätere Sicherheitsupdates fehlen.
Was passiert, wenn man Symfony-Updates über Jahre aufschiebt?
Deprecations, inkompatible Bundles und notwendige Codeänderungen summieren sich, bis ein einzelnes Update zu einem mehrwöchigen Projekt mit hohem Risiko wird. Zusätzlich fällt die Anwendung aus dem Sicherheitssupport, sobald die genutzte Version ihr Support-Ende erreicht. Ein strukturiertes Nachziehen über mehrere Minor-Versionen ist dann meist günstiger, als zu versuchen, direkt auf die aktuelle Version zu springen.
Wie testet man ein Update, ohne den Betrieb zu riskieren?
Mit einer automatisierten Testsuite, statischer Analyse und einem Blick auf neue Deprecation-Warnungen nach jedem Schritt, ergänzt durch einen manuellen Test der wichtigsten Abläufe auf einer Staging-Umgebung. Der Rollout in die Produktion erfolgt danach in kleinen Schritten mit einem vorbereiteten Rollback, damit sich ein Problem schnell eingrenzen und zurücknehmen lässt.

Weitere Ratgeber