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.
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.
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.
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 !
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/
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.
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.
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.