Aus dem nächsten Symfony-Major wird eine Zwei-Wochen-Übung statt eines Quartalsprojekts, mit Deprecation-Disziplin, Rector-gesteuerter Mechanik und einem Phasenplan, der parallel zur Feature-Lieferung läuft.
Jedes Quartal verschiebt sich das Upgrade. Deprecation-Warnungen übertönen echte Fehler in den Logs. Ein Bundle, von dem Sie abhängen, hat den Support für Ihre Symfony-Version vor sechs Monaten eingestellt, und der Security-Patch, den Sie brauchen, liegt auf einem Major, den Sie nicht erreichen.
Wir messen Deprecation-Schulden, Bundle-Gesundheit, Container-Drift und Rector-Dry-Run gegen die Ziel-Symfony-Version. Sie bekommen den realen Umfang, bevor jemand einen Liefertermin zusagt.
Bevor der Upgrade-Branch überhaupt existiert, installieren wir die Praktiken, die das Upgrade davor bewahren, ein Projekt zu werden. Deprecation-als-Fehler in CI, Rector auf jedem PR, und ein Sprint-Budget für Bundle-Hygiene.
Der eigentliche Versions-Bump in einem einzigen Branch, in der richtigen Reihenfolge. PHP-Minor zuerst, ausgeliefert, stabilisiert, dann Symfony. Rector übernimmt die mechanische Migration, wir begleiten Ihr Team durch Cutover und die erste Woche in Produktion.
Jede Deprecation klassifiziert nach Quelle, eingeführter Symfony-Version und grober Anzahl. Jedes Bundle inventarisiert mit Wartungsstatus, neuester Version und Kompatibilität zur Zielversion.
AuditEin Phasenplan mit wöchentlichen Meilensteinen, geordneter Abhängigkeitskette, risikobewerteten Schritten und einer Schätzung, die der Vorstand finanzieren kann. Inklusive PHP-Minor und einer eventuellen Asset-Pipeline-Migration als Schwesterprojekte, nicht als versteckte Posten.
FahrplanEine produktionsreife rector.php, ausgerichtet auf Ihren aktuellen und den nächsten Symfony-Major, in CI eingebunden, mit Import-Name-Policy und php-cs-fixer-Integration passend zu Ihrem bestehenden Code-Stil.
ConfigDie Deprecation-als-Fehler-CI-Konfiguration, das Bundle-Hygiene-Sprint-Budget, die framework.yaml-Drift-Prozedur und der Container-Diff-Workflow, dokumentiert als Referenz, die Ihr Team beim nächsten Major nutzt.
PlaybookDer mechanische Versions-Bump dauert ein bis drei Tage. Was länger dauert, ist Deprecation-Aufräumen, Bundle-Pflege und Container-Drift. Ein Team, das kontinuierlich gearbeitet hat, zahlt ein bis zwei Wochen pro Major. Ein Team, das drei Jahre aufgeschoben hat, zahlt drei Monate.
Nein. Der Pilot installiert Deprecation-als-Fehler und Rector, bevor der Upgrade-Branch überhaupt existiert. Cleanup läuft parallel zu Features. Der eigentliche Cutover ist ein Deploy-Fenster, kein Feature-Freeze, und meist ein einziges Off-Hours-Release.
Sie laufen die Majors nacheinander, nicht in einem heroischen Sprung. 5.4 auf 6.4 wird ausgeliefert und stabilisiert, dann 6.4 auf 7.x ausgeliefert und stabilisiert, dann 7.x auf 8.0. Sechs bis neun Monate Gesamtdauer, jede Etappe ein kurzes, fokussiertes Projekt.
Nein. PHP-Minor-Bumps haben eigene Fehlermodi (Readonly-Semantik, String/Int-Edge-Cases, neue Deprecations), und sie mit Symfony-Änderungen zu verschränken verdoppelt die Debug-Oberfläche. Wir liefern PHP immer zuerst aus, eine Woche stabilisieren, dann Symfony.
Ja. Das Deprecation- und Bundle-Audit liefert als eigenständiges Zwei-Wochen-Engagement mit Festpreis und festem Umfang. Sie bekommen den Report, den kalkulierten Fahrplan und die Rector-Konfiguration, ohne Verpflichtung zur Fortsetzung.