2. Petite introduction Marc Hugon Directeur technique chez Sensio Développeur Symfony dès les toutes premières versions (0.4 voire moins) 15 ans de pratique du web
3. Symfony2 arrive La RC1 n’est toujours pas disponible, mais le cœur est « stable » Il y a déjà un grand nombre d’earlyadopters http://symfony2bundles.org/ et ses dizaines de projets, plus de 150 bundles Et quand on voit l’activité qui entoure Symfony2, on se dit que…
4. Youpi Image TODO http://www.flickr.com/photos/reservasdecoches/3126393248/
5. Mais il y a un autre point de vue Le nombre de projets existant en Symfony1.x est assez conséquent Il est donc toujours utile et nécessaire de travailler sur ces projets Dans ce contexte, le point de vue semble un peu différent…
6. La fin du monde Image TODO http://www.flickr.com/photos/cameracapers/1245066035/
7. Quid de symfony 1 ? Ne changez rien ! Continuez à faire du symfony 1.x ! Commencez vos nouveaux projets en symfony2 si ceux-ci sont indépendants de l’existant 1.x
9. Rappel Timeline Symfony1 Première apparition publique en octobre 2005 (0.4) Février 2007 : symfony 1.0 Juin 2008 : symfony 1.1 (avec upgrade) Novembre 2008 : symfony 1.2 (avec upgrade) 2005 2008
10. Rappel Timeline Symfony1 Décembre 2009 : symfony 1.3 (avec upgrade) Décembre 2009 : symfony 1.4 Janvier 2010 : fin du support symfony 1.0 D’ici peu : fin du support symfony 1.3 Décembre 2012 : fin du support 1.4 2009 2012
11. Et pendant ce temps-là… En octobre 2005 (0.4), PHP était en version 5.0.5 En février 2007 : version 5.2.1 Juin 2008 : version 5.2.6 Novembre 2008 : version 5.2.6 Décembre 2009 : version 5.3.1 Mars 2011 : version 5.3.5 2005 2011
12. Assurer la compatibilité c’est bien Permettre de monter de version de Symfony en conservant ce qu’on avait déjà fait auparavant Mettre à jour son serveur (PHP) avec des applications qui continuent à fonctionner
13. Mais ça a un prix Impossible de profiter des évolutions du langage si on veut assurer la rétro compatibilité
14. Si on résume 7 ans de maintenance et de compatibilité PHP pour Symfony 1.x Pas mal non ? Alors maintenant, on fait quoi ?
15. On ne se limite pas Fabien Potencier en mode R&D sur Symfony2 Jour J « le routing, je vais le conserver, ce qui avait été fait sur la version 1 était pas si mal que ça » Jour J+x « finalement j’ai eu de nouvelles idées, j’ai vu des choses intéressantes là, ici, et là, j’ai tout réécrit, c’est beaucoup mieux car… »
16. Et donc Symfony2 n’assure pas la rétro compatibilité avec Symfony1 Pas d’upgrade Non Pas d’upgrade
17. Mais pourquoi ? Assurance que Symfony2 a été réalisé pour profiter au maximum de PHP 5.3 D’ailleurs Symfony2 nécessite PHP5.3.2 au minimum
18. Donc il n’y pas d’upgrade ? Hum… Je l’ai déjà dit il me semble Mais est-il quand même possible de migrer une application Symfony1.x en Symfony2?
19. Dans un monde idéal L’application source est testée unitairement et fonctionnellement Les tests sont migrés dans l’application Symfony2 Les plugins de l’application source sont traduits en bundle Symfony2 Ce qui n’était pas un plugin est porté en bundle Symfony2 Tout marche !
21. Migration des tests unitaires Pour les plus courageux : Créer une surcharge de Lime qui transforme ces appels en version PHPUnit Sinon Modifier vos tests manuellement pour les écrire en PHPUnit dans votre application Symfony1. Ils sont prêts pour Symfony2
22. Migration des tests fonctionnels Jusqu’à un certain point, les tests fonctionnels écrit en Symfony1 peuvent être réutilisés. Les problèmes commencent quand on interagit dans le cœur de l’applications sur des tests fonctionnels (appel à Doctrine par exemple)
23. Autres outils recommandés Avec un outil tel que Selenium (voire cubictest), vous faites du vrai test fonctionnel, et c’est compatible tout framework (http://cubictest.seleniumhq.org/)
24. Ok, mes tests sont prêts Prochaine étape que nous vous proposons de faire Rajouter une surcouche Symfony2 sur l’existant Symfony 1 (voir la présentation « nice performance using Sf2 cache wrapping Sf1 application » pour la façon de le faire)
25. Mais, et mes perfs ? La surcharge est très légère en terme de performances En fait, ça vous permet même très rapidement de gagner en performances ! Le cache HTTP devient en effet disponible !
26. L’ORM : le cas doctrine Symfony2 coïncide avec la mise à disposition de Doctrine2 Il est donc assez naturel de vouloir faire cette migration Mon conseil : attendez d’avoir fait le reste ! Utilisez Doctrine1 pour le moment
27. Doctrine1 et Symfony2 ? Et oui Vous pouvez utiliser un loader spécifique qui vous permettra de retrouver un auto loading compatible avec l’existant Symfony1 (MapFileClassLoader)
28. ORM : Propel Ne nécessite pas de changement majeur, c’est le même Propel https://github.com/willdurand/PropelBundle
29. Transformation plugin -> bundle L’arborescence cible la suivante (non exhaustif) : BundleName Command Controller Entity Form Resources Views Tests
30. Command Exécution de tâche disponibles dans la console symfony2 Equivalent par exemple de lib/task dans vos plugins Portage assez peu complexe, porte principalement sur les entrées / sorties
31. Controller Tous les contrôleurs sont regroupés dans un seul répertoire Dans Symfony1 ils se trouvent dans chaque module de votre plugin Comme vos contrôleurs ne contiennent pas plus de 5 lignes de code par action, la migration est simple (comme quoi une bonne pratique, ça peut servir)
32. Entity C’est le lib/model de vos plugins actuel Pas d’autres changements à apporter mis à part la problématique de l’ORM…
33. Form Le framework dédié présent dans les dernières versions de la branche 1 a été abandonné (qui n’a pas souffert sur les formulaires imbriqués ?) Symfony2 propose un nouveau framework dédié Pas vraiment de migration possible, c’est plus un travail de réécriture
34. Views Twig préconisé dans Symfony2, mais PHP est aussi supporté Sauf que… Partial, Component, Slot => Include, Slot
35. Helpers Conceptuellement, toujours présents Pratiquement, plutôt absents Mais ça ne représente que quelques lignes de code à chaque fois, migration assez simple
36. Un petit détail Le routing Symfony2 En twig : <a href="{{ path("blog_archives" }}"> Archives </a>
38. L’activation de votre bundle Quand vous vous êtes sorti des embuches précédentes Pour chaque bundle créé, vous indiquez la route correspondante dans Symfony2 et vous y êtes, Symfony2 a pris la main Au suivant, sauf que…
39. Tout ne dépend pas toujours de vous Si votre projet dépend de plugins symfony1 faits par des tiers, vous risquez de ne pas avoir de mise à jour, ou d’avoir une refonte plutôt qu’une mise à jour Un exemple ? sfGuard and co
40. Pour résumer Migration = Réécriture Heureusement, elle peut être progressive Dans la plupart des cas, vous pouvez utiliser les composants Symfony1 dans votre applicatif Symfony2 (pour les formulaires par exemple)
41. Comment faire une transition ? Chaque cas est spécifique Nombre d’applications Maintenance et évolutions Possibilité de découper les applicatifs et de les isoler Environnement technique Roadmap
42. On peut la préparer Utiliser les namespace Utiliser PHPUnit et abandonner lime pour les tests fonctionnels Utiliser le cache HTTP de Symfony2 Utiliser des composants de Symfony2 Bref, commencer à réécrire vos applications pour quitter petit à petit Symfony1
43. Un truc Plus vos applications sont découplées Plus vous respectez les bonnes pratiques Plus facilement vous pourrez travailler pas à pas sur votre migration
44. Mais n’oubliez pas Symfony1 fonctionne Symfony1 est rapide Symfony1 est maintenu Symfony2 n’est pas encore RC1
45. Quid de symfony1 ? Ne changez rien ! Continuez à faire du symfony 1.x ! Commencez vos nouveaux projets en symfony2 si ceux-ci sont indépendants de l’existant 1.x
46. Et on peut vous aider Sensiolabs propose : Une extension du support symfony1 Un accompagnement sur mesure sur votre chemin vers Symfony2 Formations Conseil Architecture Développement http://www.sensiolabs.com