Faut-il mettre à jour votre version de Symfony ?
Faisons un état des lieux complet sur le support des différentes version de Symfony. Vous y verrez plus clair sur les enjeux réels pour VOTRE projet.
Introduction
Un projet web est un projet vivant. C’est une évidence pour certains, mais on trouve énormément de projets sans aucun suivi, sur lesquels intervenir sans tout refondre est compliqué, long et coûteux.
Une fois la phase de réalisation terminée, la mise en production ne signe pas la fin du projet. C’est juste une étape dans la vie du logiciel. Commence alors une phase de maintenance.
C’est une étape cruciale, qui se doit d’être proactive pour identifier :
- les risques (bugs, fin de maintenance, failles de sécurité…)
- les opportunités (nouvelles fonctionnalités, amélioration des performances…)
On peut ainsi se prémunir des risques les plus évidents, préparer les développements à venir, planifier les mises à jour dans une période plus creuse et maintenir son projet à jour tout en maîtrisant son budget.
Voyons le cas courant d’un projet PHP développé avec le framework Symfony.
J’ai un nouveau projet à développer
Pour un nouveau projet, plusieurs possibilités s’offrent à vous, en fonction de votre contexte, l’équipe technique saura vous guider vers l’un de ces choix.
symfony 4.4 LTS
C’est la version LTS (Long-Term Support), son support est garanti jusqu’en novembre 2022, et les bugs de sécurité pendant encore un an de plus.
Ce choix apporte de la stabilité sur une période confortable, si vous vous lancez dans un petit projet, qui n’évoluera pas et dont la durée de vie tient dans les délais indiqués, cela peut se justifier.
Le nombre de librairies disponibles sur Packagist est très important, en revanche le risque est de ne plus avoir de mises à jour.
symfony 5.x
Dans la plupart des cas, votre projet est vivant et amené à évoluer. Partez sur la 5.x, c’est le meilleur choix possible. Sa durée de vie étant plus courte, vous vous engagez à faire évoluer les versions au fur et à mesure de leurs sorties. Vous êtes gagnants ! En effet, votre projet est à jour, sécurisé, et les développeurs peuvent utiliser les toutes dernières fonctionnalités du framework.
Point positif, une migration coûte moins cher si elle est faite au fil de l’eau plutôt que dans l’urgence.
Par contre, partir sur une version trop récente, c’est prendre le risque de ne pas avoir encore toutes les librairies disponibles.
La solution réside dans une juste analyse des besoins, et un suivi des versions dès que possible. Sur beaucoup de projets, une mise à jour est d’ailleurs possible avant même la mise en production. Adaptez-vous !
J’ai un projet à maintenir
Nous rencontrons encore aujourd’hui trop de projets qui ne sont pas mis à jour, parfois depuis plus de 10 ans ! Fatalement, un jour, un nouveau besoin, ou des problèmes de performance impliquent des développements longs et fastidieux, qui auraient pû être simplifiés avec un projet maintenu.
Imaginez un commerce qui ne referait jamais sa devanture, et construirait un nouveau magasin quand l’ancien ne ferait plus l’affaire. C’est tout de même plus simple et moins coûteux de mettre un coup de peinture. Une migration c’est juste un coup de jeune !
symfony 3.x
Si votre projet est encore en version 3 il est grand temps de penser à faire quelque chose. Notons que symfony 3.4 est encore maintenu, mais pas les releases précédentes. Il vous reste donc au plus quelques mois avant de prendre du retard, et puis pensez à toutes les fonctionnalités que vous n’avez pas à votre disposition : https://blog.sensiolabs.com/fr/2018/01/09/symfony-4-migration-projet-sensiolabs/
symfony 4.x
Avec un projet en symfony 4, il est important d’avoir bien en tête le calendrier. Si vous êtes encore en 4.1 ou 4.2, même sanction, vous prenez des risques ! Passez d’urgence en 4.4 minimum ! Si vous êtes en 4.3, vous avez encore quelques mois de répit, mais ne tardez pas.
Symfony 4.4, finalement c’est déjà presque symfony 5, vous avez les mêmes fonctionnalités mais avec le code déprécié des versions 4. En suivant les versions au fur et à mesure, les marches sont plus petites à chaque fois.
Évidemment, la migration en symfony 5 sera plus simple depuis la 4. Migrer depuis la version 3 implique de mettre à niveau vers la version 4 puis vers la version 5. Rien d’impossible à priori, mais un travail plus conséquent à prévoir. Votre code à déjà quelques années et les guidelines ou les process ont évolué positivement depuis.
De plus, nombre de bundles de symfony 3 n’existent plus vous mettant dans l’obligation d’une réécriture bien plus complexe avec des changements de librairies.
Un code migré n’est pas synonyme d’un projet parfaitement maîtrisé, la qualité ne se mesure pas juste avec le numéro de version ! Mais connaissez-vous les étapes d’une migration ?
Comment se passe une migration ?
Quelle que soit la migration, (PHP, Framework, librairies) les étapes sont similaires.
Lecture du changelog
C’est le point de départ. Le changelog contient toutes les informations sur la nouvelle version. Il précise les nouveautés, mais ce qui nous intéresse particulièrement, ce sont les méthode dépréciées. C’est à dire tout ce qui est obsolète et ne doit plus être utilisé. Cela peut être un appel de méthode, ou une façon de faire, d’organiser ou d’architecturer son code.
Analyse du projet / étude d’impact
Une revue de code va permettre d’identifier tous les cas d’utilisation du framework à refactoriser. Cela donnera une idée de la difficulté et du temps à investir. À cette étape, on peut aussi remarquer des effets de bord en cascade, et se rendre compte que le passage à une version plus récente impose de mettre à jour la moitié des librairies du projet. Si l’une d’entre elle n’est pas à jour, cela peut être bloquant.
On recherche avant tout la stabilité, et parfois une période d’attente s’impose avant d’entreprendre la migration.
Mise à jour du langage, du framework et des dépendances
La mise à jour du framework viendra avec la mise à jour du langage, et des dépendances. Ou l’inverse. C’est parfois la mise à jour du langage qui est le moteur de la migration, ou une nouvelle version d’une librairie qui apporte une nouvelle fonctionnalité. Dans tous les cas, c’est l’occasion de se mettre à jour, autant faire les choses bien et tout mettre à jour régulièrement.
On met donc à jour les différents composants en s’appuyant sur leur changelog pour étudier les impacts potentiels. Une fois un ensemble de composants figé dans une version stable, on peut entrer dans la phase de réécriture.
Réécriture du code déprécié
À ce moment là, souvent, plus rien ne fonctionne, et l’étape de refactorisation du code va permettre de tout réécrire. On remplace les appels de méthode dépréciées par les nouvelles recommandations. Et si certaines librairies ont changé, c’est à cette étape qu’il va falloir intégrer les ces nouvelles dépendances en lieu et place des anciennes.
Réécriture suivant les nouvelles guidelines
Mais on ne s’arrête pas là, car au delà du code, l’architecture du projet, ou son arborescence peut changer (passage à Flex par exemple).
D’une génération de framework à une autre, les recommandations changent, de nouvelles normes s’imposent, et il faut absolument en tenir compte pour finaliser la migration.
Conclusion
Plus on tarde à faire des migrations, plus le coût s’envole. C’est exponentiel ! Ne pas faire les mises à jour c’est une prise de risque ! Il faudra assumer la charge de remise en service après l’attaque, la potentielle perte de données, le manque à gagner pour un site marchand ou même l’éventuelle rançon d’un pirate…
Mais c’est également se priver de nouvelles fonctionnalités ou de gains de performances (avec PHP, c’est souvent plus de 20% à chaque version) que ne renieraient pas votre équipe technique.
