Migracja Symfony bez wyłączania firmy - jak to zrobić krok po kroku?

Dlaczego migracja jest tak trudna?

Wiele firm wciąż korzysta z rozwiązań opartych na starszych wersjach Symfony. Choć działają, nie nadążają już za wymaganiami biznesu, integracjami z zewnętrznymi systemami czy bezpieczeństwem. Klasyczna migracja „big bang” wiąże się z dużym ryzykiem przestoju, dlatego w większości przypadków lepszym podejściem jest migracja etapami.

Na produkcji w logistyce nie ma okna „wyłączymy system na kwartał”. Symfony 1.4 i 5.4 mogą żyć w jednej aplikacji, jeśli granice modułów, sesji i bazy są jawne.

Strategia: Dual Framework

W tym wdrożeniu zastosowałem podejście Dual Framework - przez określony czas współistniały dwie wersje aplikacji: stara Symfony 1.4 i nowa Symfony 5.4. Moduły przenosiłem stopniowo. Zaproponowałem uruchomienie stage, środowiska pośredniego, i tam je testowałem. Na produkcję wchodziło dopiero to, co ten etap przeszło.

Warunki brzegowe, bez których nie warto: wspólny model tożsamości, jasny owner modułu, zakaz spaghetti między kernelami. Docker i Linux jako stałe tło - nie jako afterthought.

Praktyka z ERP transportowego: nowe fakturowanie i KSeF wchodzą na nowszy kernel, magazyn operacyjny zostaje na 1.4, aż skończy się migracja. Wspólne uprawnienia (Voter) i jedno repo Git.

# Przykład konfiguracji routingu
legacy:
    resource: '@LegacyBundle/Controller/'
    type: annotation
    prefix: /legacy

modern:
    resource: '@App/Controller/'
    type: annotation
    prefix: /

Co dalej

Jeśli stoisz przed skokiem 2.x/3.x → 7, zacznij od mapy zależności i planu cut-over, nie od pustego skeletonu. To nie jest oferta „przepiszę Wam wszystko w sprintach”. To oferta „zostawię Wam działający system po drodze”.