Migrer de Symfony 3 à Symfony 4 n'est pas aussi simple qu'on ne le pense... Plus de précisions dans cet article

Symfony 5 est sortie en novembre 2019, tout comme la dernière LTS (Long Term Support), la version 4.4.

Pour ne pas être trop en retard, j'ai procédé à la migration d'une application web avec une interface REST de la version Symfony 3.4 à 4.4. Simple, diriez vous ?
Et bien, pas tant que ça...

Quelques principes...

En théorie, passer d'une version 3.4 à 4.4 se fait facilement: tout dépend de comment on veut procéder et de comment on veut structurer notre projet une fois migré.
Il est tout à fait possible de garder la même structure de SF3 dans SF4 avec quelques configurations... Mais je ne l'ai pas fait donc je ne pourrai pas confirmer.

En revanche, j'ai migré le projet suivant la structure Symfony 4.4, donc les bundles personnels de l'ancienne version ont du être refactorisée par exemple.

Avant d'aborder cette migration, voici les différences entre Symfony 3, Symfony 4 et Symfony 5:

Symfony 3 et Symfony 4

Voici une liste des principales différences:

• les fonctionnalités obsolètes de la 3.4 supprimées.
• nouvelle structure du projet.
• version allégée, qui supprime toute dépendance inutile.
• déploiement rapide.
• Symfony Flex: surcouche pour gérer l'installation et le déploiement des bundles.

Pour la version 4, le déploiement a été repensé et allégé afin de founir uniquement les composants nécessaires au fonctionnement du coeur Symfony. Le but est de répondre aux besoins des utilisateurs qui n'utilisent que certains composants de Symfony, ou encore faciliter le développement des applications axées sur les micro-services.

Finis les bundles personnels de Symfony 3, la nouvelle structure améne:

• un dossier config avec toute la configuration du projet, organisée en plusieurs fichiers indépendants (il n'y a plus de config.yaml).
• un dossier src avec les controllers, les entités, les événements, etc...
• un dossier templates avec les vues.
• un dossier public pour le nouveau point d'entrée de l'application Web (en remplacement de web)
• un fichier .env pour les paramètres et variables d'énvironnement (équivalent au fichier parameters.yaml)

Avec Symfony Flex, il est désormais plus simple d'installer les bundles, avec la possibilité d'utiliser des recipes (scripts de configuration du bundle). Il suffit désormais d'éxécuter composer require <notre_bundle> pour installer le bundle.

Symfony 4 et Symfony 5

Le lien suivant énonce très bien les nouveautés apportées par Symfony 5.

Mais je vous en donne quand même une liste des principales:

• nouvelles méthodes Dom Crawle: principalement uitilisées pour les tests fonctionnels et pour intéragir avec les éléments du DOM.
• gestion des secrets cryptés: permet des gérer les informations sensibles (connexion à la DB par exemple), de manière cryptée.
• un composant String pour les objets concernant du texte.
• un composant Notifier qui permet d’envoyer des notifications sur plusieurs supports

Sachez également que la version 4.4 est identique à 5.0.

La migration

La plus grande difficulté est le changement de structure, car chaque fichier doit être déplacé / copié / mergé dans la nouvelle. Il m'a fallu environ 10 jours pour obtenir une première version fonctionnelle, sans pour autant écarter tout risque de bugs liés à la migration.

J'ai également rencontré des problèmes de compatibilités:

• le composant EventDispatcher: l'implémentation de la méthode dispatch() a changé entre la version 3.4 et 4.4. Il a fallut réimplémenter tous les calls du projet.
• les assertions: la nouvelle bonne pratique est d'utiliser les annotations, il a fallu refactoriser les assertions en annotations.
• le bundle FOSUserBundle: pour supprimer la dépendance, j'ai du réintégrer le bundle et supprimer les fonctionnalités non utilisées.
• le bundle FOSRestBundle: ce bundle n'est pas 100% compatible avec Symfony 4 et les exceptions de type FlattenException ne sont pas bien gérées. Il a donc fallu patcher le bundle.
• le bundle JMSSerializer: il a fallu refactoriser les éléments de sérialisation de yaml aux annotations. De plus, les stratégies d'exclusions ne sont pas les mêmes.J'ai donc changé de stratégie et réadapté le résultat.

Le plus gros du travail était de debugguer et comprendre les différents dysfonctionnements.

Si vous devez faire ce genre de tâche, ces infos vous aideront peut être.

Je vous dis à plus pour le prochain article.

Previous Post Next Post

---