NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüner Kran hebt Container für das Symfony Upgrade mit Rector

Was ein Symfony Upgrade mit Rector bedeutet

Ein Symfony Upgrade mit Rector hebt eine bestehende Symfony Anwendung auf eine neue Major Version und lässt Rector dabei wiederkehrende Code Änderungen automatisch erledigen. Der Weg führt immer über die letzte Minor Version der alten Reihe, zum Beispiel 6.4, weil dort alle Deprecations sichtbar werden.

Symfony entfernt bei jedem Major Release genau die Funktionen, die vorher als veraltet markiert waren. Wer seinen Code vorher von diesen Deprecations befreit, kann fast ohne Brüche wechseln. Rector übernimmt dabei die Fleißarbeit, etwa Annotations in PHP Attribute umzubauen oder geänderte Signaturen anzupassen. Tests und statische Analyse sorgen dafür, dass das Verhalten der Anwendung gleich bleibt, während sich der Code darunter verändert.

Inhalt

Symfony Upgrade mit NCA, schnelle Hilfe vom Experten

Unsere eigene Plattform läuft auf Symfony und Sulu CMS. Jedes Symfony Upgrade machen wir also nicht nur für Kunden, sondern zuerst für uns selbst. Rector, PHPStan und PHPUnit laufen bei jedem Commit, Cypress prüft die Oberfläche. Wir wissen deshalb, wo ein Upgrade in Stunden erledigt ist und wo es weh tut: bei Bundles ohne Update, bei eigener Konfiguration in YAML und bei Tests, die selbst auf veralteten APIs stehen.

Im PHP Update bringen wir Symfony und PHP gemeinsam auf eine unterstützte Version. Im PHP Consulting planen wir den Weg mit eurem Team, beim PHP Refactoring räumen wir auf, was beim Upgrade sichtbar wird. Die Werkzeuge dazu erklärt das Glossar zu Rector PHP und zum Symfony Framework. Vor dem PHP Sprung prüft PHPCompatibility den Code auf die Zielversion.

Lass uns sprechen
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Welches Ziel für euer Upgrade richtig ist

Symfony veröffentlicht alle sechs Monate eine Minor Version und alle zwei Jahre eine Major Version. Die letzte Minor Version jeder Reihe ist eine Long Term Support Version mit drei Jahren Bugfixes und einem weiteren Jahr Sicherheitsupdates. Laut dem Symfony Release Kalender endet die Bugfix Phase von 6.4 im November 2026, Sicherheitsupdates gibt es noch bis November 2027.

Daraus ergeben sich zwei sinnvolle Ziele:

  • Symfony 7.4 LTS für Teams, die Ruhe wollen. Es braucht PHP 8.2 oder höher und bekommt laut Kalender Bugfixes bis November 2028.
  • Die aktuelle 8er Version für Teams, die neue Features nutzen und regelmäßig nachziehen. Symfony 8 setzt PHP 8.4 voraus, jede Minor Version wird nur wenige Monate gepflegt.

Für die meisten gewachsenen Anwendungen empfehlen wir den Weg auf 7.4 LTS. Wer dort sauber ohne Deprecations angekommen ist, hat den Sprung auf Symfony 8 schon zum größten Teil vorbereitet.

Vor dem Upgrade, das Netz aufspannen

Ein Upgrade ändert viele Dateien auf einmal. Ohne Tests merkt ihr Fehler erst, wenn Nutzer sie melden. Deshalb steht vor jedem Upgrade die gleiche Checkliste:

  • Alle Tests laufen grün. Wer mit roten Tests startet, kann neue Fehler nicht von alten unterscheiden.
  • PHPStan läuft in der Pipeline, mit der Symfony Extension und einer Baseline für Altlasten.
  • Functional Tests decken die wichtigsten Controller ab, mit WebTestCase oder KernelTestCase.
  • Cypress Tests prüfen die kritischen Wege durch die Oberfläche, etwa Login, Checkout oder Formulare.
  • Composer Audit ist sauber und alle Abhängigkeiten sind auf ihrem neuesten kompatiblen Stand.

Fehlen Tests für alte Bereiche, helfen Characterization Tests. Sie halten fest, was die Anwendung heute tut, und melden jede Abweichung nach dem Upgrade.

Schritt eins, Deprecations sichtbar machen

Zuerst geht die Anwendung auf die letzte Minor Version der aktuellen Reihe, also 6.4 vor dem Sprung auf 7. Erst dort zeigt Symfony alle Deprecations, die mit der nächsten Major Version entfallen. Im Dev Modus seht ihr sie in der Web Debug Toolbar, in den Tests über die PHPUnit Bridge.

Code: 
          
composer require --dev symfony/phpunit-bridge

./bin/phpunit

Am Ende des Testlaufs listet die Bridge alle verbleibenden Deprecations mit Anzahl und Fundstelle. Viele kommen aus Bundles von Drittanbietern. Dort hilft meist ein Update des Pakets. Was ihr noch nicht beheben könnt, lasst ihr über die Umgebungsvariable SYMFONY_DEPRECATIONS_HELPER vorübergehend zu, damit die Pipeline grün bleibt, während ihr die Liste abarbeitet.

Ziel ist eine Testausgabe ohne Deprecations. Dann ist der Code laut Symfony Dokumentation zukunftskompatibel und der eigentliche Wechsel wird zur Formsache.

Schritt zwei, Rector die Fleißarbeit machen lassen

Rector erkennt die installierten Versionen von Symfony, Doctrine, Twig und PHPUnit direkt aus Composer und wählt passende Regelsätze aus. Eine Zeile in der Konfiguration reicht dafür:

Code: 
          
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
    ->withComposerBased(symfony: true, doctrine: true, twig: true, phpunit: true);

Rector läuft zuerst immer als Trockenlauf. Ihr seht den Diff, prüft ihn und wendet ihn erst dann an.

Code: 
          
vendor/bin/rector --dry-run

vendor/bin/rector

Die Rector Dokumentation empfiehlt, langsam einzusteigen: wenige sichere Regeln zuerst, kleine Pull Requests, die am selben Tag reviewt werden. Für PHP Versionen hilft das schrittweise Anheben über Level statt aller Sets auf einmal. Typische Umbauten beim Symfony Upgrade sind Annotations zu PHP Attributen, Constructor Injection und angepasste Signaturen von Event Subscribern und Commands.

Rector nutzt PHPStan, um Typen zu verstehen. Je besser euer PHPStan Level, desto mehr kann Rector sicher umbauen.

Schritt drei, Composer und Recipes aktualisieren

Ist der Code frei von Deprecations, folgt der eigentliche Versionswechsel. In Projekten mit Symfony Flex setzt ihr die Zielversion zentral im Bereich extra der composer.json und aktualisiert danach alle Symfony Pakete.

Code: 
          
composer update "symfony/*" --with-all-dependencies

rm -rf var/cache/*

composer recipes:update

Den Cache löscht ihr direkt im Dateisystem, weil die Anwendung nach dem Update eventuell noch nicht bootet. Danach gleicht recipes:update eure Konfigurationsdateien mit den aktuellen Recipes ab und erzeugt Patches, die ihr wie normale Git Konflikte auflöst. Committet vorher alle anderen Änderungen, damit der Diff übersichtlich bleibt.

Zum Schluss lest ihr die UPGRADE Datei der neuen Major Version im Symfony Repository. Dort stehen die seltenen Brüche, die nicht über Deprecations angekündigt werden konnten.

Symfony Upgrade in fünf Schritten

Schritt Werkzeug Ergebnis
1. Absichern PHPUnit, Functional Tests, Cypress, PHPStan Grüne Pipeline als Ausgangspunkt
2. Letzte Minor Composer, PHPUnit Bridge Alle Deprecations sichtbar
3. Umbauen Rector mit Composer basierten Sets Code ohne Deprecations
4. Wechseln Composer Update, Recipes Update Neue Major Version installiert
5. Prüfen Kompletter Testlauf, Review, Staging Gleiches Verhalten auf neuer Version

Typische Stolperstellen beim Symfony Upgrade

Bundles ohne neue Version. Ein einziges nicht gepflegtes Bundle kann das ganze Upgrade blockieren. Prüft vorher, ob alle Pakete die Zielversion unterstützen. Für verwaiste Pakete braucht ihr einen Ersatz oder einen eigenen Fork.

PHP und Symfony gleichzeitig springen. Zwei große Wechsel auf einmal machen Fehler schwer zuzuordnen. Besser erst PHP anheben, dann Symfony, oder umgekehrt, jeweils mit grüner Pipeline dazwischen.

Alte Konfiguration in YAML. Eigene Konfiguration lässt sich mit dem Config Transformer in PHP überführen. Danach greifen auch die Rector Regeln für Config Builder.

Tests auf alten PHPUnit APIs. Oft hängt das Upgrade an der Testsuite selbst. Rector bringt mit dem PHPUnit Set auch die Tests auf eine aktuelle Version.

KI Agent macht alles auf einmal. Ein Coding Agent schafft ein Upgrade in einem riesigen Diff, den niemand mehr prüfen kann. Kleine Schritte mit Rector und ein Mensch im Review sind langsamer im Gefühl, aber schneller im Ergebnis.

The maintenance of a software project must not only be reactive.

Sebastian Bergmann, Erfinder von PHPUnit und Mitgründer von thePHP.cc – Help! My tests stopped working

Die NCA Erfahrung mit Symfony Upgrades

Symfony Upgrades gehören bei uns zum normalen Betrieb, in der eigenen Plattform und in Kundenprojekten. Die Werkzeuge, die dabei zum Einsatz kommen, findet ihr im Glossar.

Den Umbau übernimmt Rector PHP, YAML Konfiguration wandelt der Config Transformer um. Abhängigkeiten prüfen Composer Dependency Analyser und Composer Audit. Typen sichert PHPStan, das Verhalten PHPUnit mit Functional Tests und dem Symfony KernelTestCase. Für alte Bereiche ohne Tests nutzen wir Characterization Tests. Den Stil halten die Symfony Coding Standards einheitlich. Die vielen kleinen Commits eines Upgrades räumt Git Interactive Rebase vor dem Merge auf. Welche Sprachfeatures die neue PHP Version bringt, zeigt der Vergleich der PHP 8 Versionen.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Erreichen Sie unsere PHP Consultant Spezialisten

Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.

Demo Team Workshop Anrufen

Häufige Fragen zum Symfony Upgrade mit Rector

Was Teams vor und während eines Symfony Upgrades am häufigsten wissen wollen.

Auf welche Symfony Version sollte ich 2026 upgraden?

Für die meisten gewachsenen Anwendungen auf Symfony 7.4 LTS. Diese Version bekommt laut Symfony Release Kalender Bugfixes bis November 2028 und braucht PHP 8.2. Teams, die neue Features nutzen und regelmäßig nachziehen wollen, gehen direkt auf die aktuelle 8er Version mit PHP 8.4.

Wie lange wird Symfony 6.4 2026 noch unterstützt?

Laut Symfony Release Kalender endet die Bugfix Phase von 6.4 im November 2026. Sicherheitsupdates gibt es noch bis November 2027. Danach läuft die Anwendung ohne offizielle Patches. Wer jetzt plant, hat genug Zeit für ein Upgrade in Ruhe statt unter Druck.

Kann Rector 2026 ein Symfony Upgrade komplett automatisch machen?

Einen großen Teil, aber nicht alles. Rector baut wiederkehrende Muster deterministisch um, etwa Annotations zu Attributen oder geänderte Signaturen. Bundles ohne Update, eigene Sonderlösungen und fachliche Fragen bleiben Handarbeit. Tests und ein Review sichern jeden Schritt ab.

Wie konfiguriere ich Rector 2026 für Symfony?

Mit withComposerBased und dem Parameter symfony auf true. Rector liest dann die installierte Symfony Version aus Composer und wählt passende Regeln. Doctrine, Twig und PHPUnit lassen sich genauso einschalten. Vor dem Anwenden läuft Rector immer zuerst als Trockenlauf mit Diff.

Darf ich 2026 direkt von Symfony 5.4 auf 7.4 springen?

Der sichere Weg führt über die letzte Minor Version jeder Reihe, also 5.4, dann 6.4, dann 7.4. Nur dort seht ihr alle Deprecations der nächsten Major Version. Jede Station bekommt eine grüne Pipeline, bevor es weitergeht. Das ist schneller, als einen großen Sprung zu debuggen.

Was sind Deprecations und warum sind sie so wichtig?

Deprecations markieren Funktionen, die in der nächsten Major Version entfallen. Sie funktionieren noch, erzeugen aber Hinweise. Wer alle Deprecations behebt, solange er auf der letzten Minor Version ist, kann die nächste Major Version fast ohne Brüche installieren. Die PHPUnit Bridge listet sie im Testlauf auf.

Sollte ich PHP und Symfony gleichzeitig upgraden?

Besser nicht. Zwei große Wechsel auf einmal machen Fehler schwer zuzuordnen. Hebt zuerst PHP auf eine Version an, die alte und neue Symfony Version unterstützen, und wechselt dann Symfony. Zwischen beiden Schritten sollte die Pipeline grün laufen.

Was mache ich mit Bundles, die kein Update bekommen?

Zuerst prüfen, ob es einen gepflegten Ersatz gibt. Oft ist ein Bundle inzwischen überflüssig, weil Symfony die Funktion selbst mitbringt. Bleibt keine Alternative, hilft ein eigener Fork oder das Herauslösen der Funktion in eigenen Code, abgesichert durch Tests.

Was macht composer recipes:update?

Der Befehl vergleicht eure Konfigurationsdateien mit der aktuellen Version der Symfony Recipes. Er erzeugt einen Patch und wendet ihn an. Konflikte löst ihr wie bei Git. Vorher solltet ihr alle anderen Änderungen committen, damit der Diff übersichtlich bleibt.

Welche Tests brauche ich vor einem Symfony Upgrade?

Mindestens Functional Tests für die wichtigsten Controller und E2E Tests mit Cypress für die kritischen Wege durch die Oberfläche. Dazu statische Analyse mit PHPStan. Bereiche ohne Tests sichert ihr über Characterization Tests ab, die das heutige Verhalten festhalten.

Kann ein KI Agent das Upgrade übernehmen?

Er kann helfen, Deprecations zu erklären und einzelne Anpassungen vorzuschlagen. Ein komplettes Upgrade in einem riesigen Diff lässt sich aber nicht mehr sinnvoll prüfen. Wir setzen auf Rector für deterministische Umbauten, kleine Pull Requests und ein menschliches Review für jeden Schritt.

Wie unterstützt Never Code Alone beim Symfony Upgrade?

Wir prüfen eure Abhängigkeiten, bauen fehlende Tests auf und führen das Upgrade gemeinsam mit eurem Team in kleinen Schritten durch. Am Anfang steht ein kostenloses Kennenlernen mit Blick in den Code. Den Aufwand schätzen wir danach und rechnen transparent nach Minuten ab.