La migration continue vers Symfony

1. Lamigrationcontinue versSymfony FrançoisZaninotto-SimonRolland L’agilitésansfeuilleblanche

2. SimonRolland ChefdeprojetTechnique20Minutes #php#medias @SIm07 FrançoisZaninotto CEOmarmelab Symfonydoc-Propel -Faker-Gremlins.js #agile#symfony#js @francoisz néle8avril1974

3. Stratégies d’Architecture logicielle Stratégies d’Infrastructure Stratégies Méthodologiques Iln’yapasderaison queçasepassemal

4. Larefonte20Minutes enchiffres

5. 3èmesite de news, premier quotidien d’info papier 90millions de pages vues sue le web(sourceOJDjuillet2013) 106millions de pages vues sur mobiles et tablettes (sourceOJDMobilejuillet2013) 120rédacteurs utilisent le système en 24/7 800000articles à migrer 1400000lignes de code à migrer (PHP + Symfony 1.2) 6moisde délai

6. ObjectifEtna

7. ObjectifEtna • Etna est le CMS de marmelab. • A nous tous, on a développé près d’unedemi-douzaine de CMS par le passé. Ca nous a permis de comprendre les bonnes pratiques, et on a mis le meilleur dans Etna. • CMS sur base Symfony 2 + Entrepôtdocumentaire (Jackrabbit) + Symfony CMF • Communication asynchrone RabbitMQ + toutes les listes sur base ElasticSearch • Interface backend Sonata / Backbone.js • Pas open-source, désolé • Périmètre de la migration 20 Minutes : coeur CMS, BO édition des contenus, BO edition home page, front-office

8. Lamigration: uneformalité?

9. Lamigration:uneformalité? • Le passage d’un système à un autre se fait au cours d’un évènement festif et maîtrisé qu’on appelle la migration. • La migration intervient, en général, àlafin d’un projet de refonte • Il s’agit simplement de basculer les utilisateurs, les données, et les fonctionnalités d’un système vers un autre. • Mais quelquefois, ce n’est pas si simple. • Sur la base des migrations ratées que j’ai pu vivre, j’ai imaginé quelques scénarios catastrophe pour la migration 20 Minutes. Vous avez peut-être déjà vécu ces histoires-là vous aussi.

10. ATTENTION' CE'FLIM'S’INSPIRE' DE'FAITS'REELS MERCI'DE'VOTRE' COMPREHENSION

11. NeverendingStory Scénariocatastrophen°1

12. Scénariocatastrophe#1 • Pour éteindre un système, il faut que tous les systèmes qui en dépendent soient migrés • Cela veut dire qu’il faut modifier ou réécrire des tas d’applicationspasdutoutprioritaires. Pour 20 Minutes, il faut migrer : • Des applications mobiles pas très smart (Blackberry, Samsung/Bada, etc) • Des exports vers des partenaires qui vont s’arrêter quelques mois après la migration • Des analytics qui tapent directement en base • Des centaines d’autres petites applications • On ne peut donc commencer la bascule effective que quand ladernièreapplication (la moins prioritaire) est refondue. • Dans ce scénario, la migration effective n’intervient pas 6 mois après le début du projet, mais 24 mois.

13. L’anciensystème Neserajamaiséteint Leçonn°1

14. Leçonn°1 L’anciensystèmeneserajamaiséteint • Ne pas mettre l’extinction de l’ancien système soit sur le chemin critique • Trouver des moyens de migrer des portionsd’applications • Trouver des moyens de nepasmigrer les applications on prioritaires • Prioriser les migrations selon la valeurbusiness

15. Scénariocatastrophen°2 JohnCarter

16. Scénariocatastrophe#2 • Les limites du système actuel résident surtout dans un modèlededonnées devenu inadapté • La refonte consiste donc en une réécrituredescouchesbasses, sans valeur apparente pour les utilisateurs • Pour ne pas compliquer les choses, on fait une refonte à isofonction • Pendant la refonte, les développeurs sont à fond sur le nouveau système ; l’ancien est abandonné en l’état, ses évolutions repoussées sine die • Les utilisateurs ne voient aucunchangementpendant6mois • A la mise en production, les besoins ont changé, et le nouveau système est moins bien que l’ancien (puisque buggué) • Les utilisateurs boudent la nouvelle appli, le projet est à la foisungouffreetunfour

17. Pasdemigration sansvaleurmétier Leçonn°2

18. Leçonn°2 Pasdemigrationsansvaleurmétier • Impliquerlesutilisateurs très en amont pour comprendre leurs vrais besoins • Mêler migration technique et évolutions • Mettreenproduction dès les premières étapes pour ajuster en cas de dérive • Donner de la visibilité sur l’avancement de la migration • Peu importe le défi technique : se concentrer sur le bénéficeutilisateur

19. Scénariocatastrophen°3 PokemonXVI

20. Scénariocatastrophe#3 • Pour le nouveau système, on conçoit un modèlededonnées flambant neuf • Il faut importer les données de l’ancien système dans le nouveau. 800 000 articles ! Au cours de la mise en production, l’import prend 48h à s’exécuter • Les utilisateurs commencent à apprivoiser le nouveau système. Petit à petit, on découvre des casparticuliers de l’ancien système que l’import n’a pas bien géré • Il faut corriger l’import et le rejouer. Mais les utilisateurs ont déjà commencé à ajouter des données sur le nouveau système. Ces modificationsserontperdues en cas de réimport. • On développe donc un export dans l’autre sens, qui prend 36h à s’exécuter. • Le site est en indisponibilité 2 jours par semaine pendant 2 mois

21. Lesmigrationsde donnéessontcoeur Leçonn°3

22. Leçonn°3 Lesmigrationsdedonnéessontcoeur • Ne pas attendrelafinduprojet pour développer les migrations. • Les données initiales sont toujoursenmauvaisétat. Prévoir beaucoup de temps pour les cas particuliers. • Optimiser les imports / exports, car ils seront joués plein de fois (même si vous croyez qu’ils ne le seront qu’une seule fois). • Testerunitairement les imports / export • Comparer les pages générées par l’ancien et le nouveau système pour validerlaboucle d’import / export (legacy => new => legacy) • Trouver des mécanismes demiseàjournonbloquants / asynchrones pour ne pas empêcher l’utilisation du CMS pendant un réimporte / réexport (cron, AMQP)

23. LaMigration Ancien système Nouveau systèmeAncien système Boutonrouge

24. Lamigration« boutonrouge » • Tous ces scénarios catastrophe partent de la même erreur initiale. La migration y est vue comme un évènementponctuel, où on appuie sur un bouton rouge pour passer instantanément d’un ancien système à un nouveau système. (les anglais disent « big bang ») • Ca ne se passe jamais comme ça. • Pour ne pas reproduire les erreurs du passé, il faut repenser les stratégies de migration. • Un des préceptes de l’agilité dit « siçafaitmal,faites-leplussouvent ». C’est pour cela qu’on parle de déploiement continu, d’intégration continue, etc. • On peut appliquer ces principes à la réécriture d’un système. Cela s’appelle logiquement la « migrationcontinue » - les anglos-saxons parlent d’incremental migration.

25. LaMigration Continue

26. Lamigrationcontinue • Au lieu de basculer d’un coup de l’ancien sur le nouveau système, on prévoit de faire passer progressivement les utilisateurs, les données, et les fonctionnalités de l’ancien vers le nouveau système. • Si vous ne devez retenir qu’une chose de cette présentation, c’est ce schéma. Tout est dedans. • C’est un peu comme si on habitait une maison en construction dès que le premier coup de pelleteuse est donné… sauf qu’en développement web, c’est possible.

27. Stratégies d’Infrastructure Iln’yapasderaison queçasepassemal Stratégies d’Architecture logicielle Stratégies Méthodologiques

28. Migreràchaque Itération

29. Migrerparitérations • Qui dit amélioration continue dit agilité. On pense immédiatement à SCRUM, mais il faut aller plus loin. • Les principes de l’agilité projet peuvent aussi être appliqués au produit: • Mener un projet agile : améliorer le cycleprojet par la prise de feedbacks dans l’équipe projet • Construire un produit agile : améliorer le produit par la prise de feedbacks chez les utilisateurs du produit

30. Migrate Measure Learn

31. Migrerparitérations • Une premièremigrationASAP, dans l’idéal dès la troisième semaine (en pratique, au bout de 3 mois) • Au moins unemigrationtoutesles2semaines, avec le résultat des 2 dernières semaines de dév. (obligés de découper grosses tâches de migration en plus petites, et de les prioriser tôt). • La priorisation se fait par le niveauderisque : bascule données, fonctionnalités et organisations les plus critiques en 1er. S’il faut se planter, autant s’en rendre compte tout de suite pour pouvoir pivoter. • Mesurer l’effet de chaque migration pour en valider l’action (ex). Si migration sans effet sur une métrique utile, ne pas la faire. • En fonction des retours d’utilisation, on se force à reprioriser toutes les deux semaines. • Cette agilité produit a un nom: c’est le LeanStartup : concevoir chaque fonctionnalité comme une expérimentation pour prouver une hypothèse (ex : je peux réduire le temps de saisie d’un article de 20% en évitant les copier / coller outlook / word / CMS)

32. Associer  Le métier

33. Associerlemétier • Imaginez que, dans votre cuisine, les meubles changent un peu tous les jours, et que donc les ingrédients, les ustensiles se retrouvent rangés à des endroits différents. Ca serait trèsénervant. L’informatique, c’est la cuisine des rédacteurs. • Les pratiquesmétier n’évoluent pas en continu, pas au même rythme que les SI. • Enjeux rédaction : supporter une migration continue. • Prévenir la résistanceauchangement • Apprendre sans trop passerdetempsenformation (ou sans attendre une formation, qui doit être planifiée) • Minimiser le tempspasséàbasculer d’un outil à un autre, l’entropie créée par la migration • Maîtriser l’ascenseurémotionnel, qui descend vite après les premières heures d’utilisation)

34. Personas Train Sell Early Adopters Communicate PilotAdapt Participate

35. Associerlemétier • Moyens : conduite du changement, avec particularités • Créer de l’empathie et des interactions avec les utilisateurs dès le début du projet : • Individualisation via les personas • On fait participer les utilisateurs aux ateliers d’exploration fonctionnelle, à la priorisation et aux démos. • Donnerenvie à ceux qui n’ont pas basculé de le faire, par la communication, les démos publiques, des teasers • Basculer les utilisateurs paréquipes, en commençant par une équipe pilote : les early adopters. Plus tolérant, plus enthousiastes, plus exigeants. Evangélistes : une fois convaincus, ils seront les ambassadeurs du nouveau système. • Inciter à la remontée d’information avec un boutondefeedback et en s’assurant que la porte du bureau du PO est toujours ouverte • Etre très réactif sur la correction de bug, donc prioriserlesbugfixes dès la seconde itération • Former en continu aux nouveautés

36. FairesentirLechangement

37. Fairesentirlechangement • Une migration d’un SI coeur de métier est un projetd’entreprise. Toute l’entreprise doit y être associée • Enjeux • Les utilisateurs doivent donner leur confiance à un outil pasfinalisé • les utilisateurs doivent sentir que leurs retours sont pris en compte pour continuer à en donner • la DSI doit voir les choses avancer alorsmême qu’on n’a pas de vision globale exacte (problème inhérent à l’agilité) • Il faut des changementsvisibles à chaque itération • Moyens • Etre très réactif sur la correctiondebug, donc prioriserlesbugfixes dès la seconde itération • Prioriser les bascules d’équipes / d’outils (donc prioriser les migrations sur les nouvelles features) • Offrir une visualisation du pourcentagedel’ancienSImigré

38. Fairesentirlechangement • Pour visualiser l’avancement de la migration 20 Minutes, on a commencé par cartographierl’existant, en rassemblant les fonctionnalités par application, et en évaluant leur niveau de complexité. Ca donne cette carte. • Puis on a renseigné le pourcentage de migration de chaque composant au fur et à mesure du projet. • La carte s’est mise à jour toute seule (grâce à d3.js). • C’est un excellent vecteurdecommunication du changement.

39. Stratégies d’Infrastructure Stratégies Méthodologiques Iln’yapasderaison queçasepassemal Stratégies d’Architecture logicielle

40. Découperen Services

41. Découperenservices • Enjeux • Cette migration ne sera pas la dernière (on l’espère). Il faut que la prochaine migration soit plus simple. • Ce qui a rendu la migration difficile, c’est le côté monolithique de l’application • On n’utilise plus aujourd’hui une seule techno pour tout (avant : PHP. Aujourd’hui : Varnish, ElasticSearch, etc). • On veut pouvoir faire évoluer l’application par morceaux, indépendamment de l’ensemble

42. AMQP SOA InterfaceRESTStandardHTTP Microservices Guzzle RabbitMQ

43. Découperenservices • Moyens • On choisit donc de découper le nouveau système en services (=applications) indépendants • Chaque service utilise sa propre technologie. • Mais les services doivent savoir communiquer entre eux de manière standardisée. HTTP REST (avec Guzzle) / AMQP (avec RabbitMQBundle) • Exemples • Interrogation des comptes sociaux : Node.js • Affichage des images : Python • API médiathèque : Silex • Gestion page d’accueil : SPA Backbone • Workers Rabbit : Symfony2 • Limites • Complexité du développement avec n services à installer

44. Synchroniser Lespersistences Legacy New

45. Synchroniserlespersistences • Enjeux • Contrainte : Les Back-offices des 2 outils doivent pouvoir être utilisés en parallèle, puisque la migration ne concerne qu’une partie des équipes, ou des rubriques, ou des fonctionnalités. Les données peuvent être modifiées de part et d’autre. • Les données doivent être synchroniséesdans les deux back-office • Le référentiel reste Legacy jusqu’à la bascule finale • Les modèles de données sont différents (contraint par l’existant sur legacy, idéal sur New) • Pasdemodificationdedonnée possible côté Legacy

46. Synchroniserlespersistences • Moyens • Persistence de la correspondance new/legacy côténew • Synchronisation Asynchrone via Consumers RabbitMQ • Exporter et importer sont des services, déclenchés par le BO / les imports partenaires / des commandes (pour l’import initial ou la récupération) • L’import et l’export ne sont pas déclenchés par un hook ORM « postPersist » pour éviter une boucle infinie • Les services Importer et exporter sont unittestés à fond, profilés et optimisés pour un temps d’exécution réduit • La boucle totale (import et réexport) est testée sur des centaines de milliers d’articles existants pour vérifier qu’on ne change rien

47. Supprimerles  Couplages 1001 1003 1005 1002 1004 1006

48. Supprimerlescouplages • Enjeux • Des fonctionnalités du nouveau BO nécessitent un identifiantdecontenuvenant delegacy (ex: contenus liés) • Legacy utilise une séquenceMYSQLautoincrémentée pour générer les id de contenus • L’attente d’un legacy id en asynchrone dégrade l’expérience utilisateur en back- office (ex : pas d’id immédiatement après création, nécessite un refresh) • Il faut donc que New sache, au même titre que Legacy, créerdesLegacyId • Mais il faut éviterlesconflits (ex: New crée un contenu en même temps que Legacy, ils prennent le même id pour deux contenus différents) • Pas de moteurdegénérationd’idtransactionnel côté New (Jackrabbit, pas MySQL)

49. Supprimerlescouplages • Moyens • On utilise des incrémentsd’indexde2en2 côté legacy et new • Séquences paires et impaires pour éviter les conflits. Legacy : 1001, 1003, 1005. New : 1002, 1004, 1006 • New utilise un Servicedeséquences spécialisé (basé sur table unique MySQL et des transactions) • Les séquences de New sont synchrones, ça permet donc de garantir l’intégrité et la non-duplicité d’id

50. Migrerlespages  parblocs

51. Migrerlespagesparblocs • Enjeux • Les pages d’un CMS contiennent beaucoupd’éléments (menus, body, blocs sociaux, contextuels, tags, rebonds, pubs…) • Attendre d’avoir migré tous les éléments pour pouvoir migrer la page, c’est troplong

52. Header Article Footer Pub Tags Local Legacy New

53. Header Article Footer Pub Tags Local Header Article Footer Pub Tags Local Legacy New

54. Legacy New Header Article Footer Pub Tags Local Header Article Footer Pub Tags Local Header Article Footer Pub Tags Local

55. Migrerlespagesparblocs • Moyens • Recomposer une page à partir de backendsdifférents : SSI (non), ESI (facile avec SF2), Ajax • Migrer les blocs unparun, en vérifiant que tout ce passe bien (notamment niveau performance) • RegrouperlesESI une fois migré un ensemble cohérent (ex = Titre + chapo + Body = Article) • Utiliser un reverseproxy qui aiguille les requêtes internes (et les protège d’un accès extérieur) • Migrer le contrôleur de pages endernier, quand tous les éléments de page sont migrés (à moins de pouvoir inclure un ESI sur Legacy…) • Limite • Larefontegraphique, qui ne sait pas se faire de façon continue

56. Découpler  lesmigrations

57. Découplerlesmigrations • Enjeux • La médiathèque, qui gère images et métadonnées d’images, doit être migrée elle aussi • Le planning de la migration de la médiathèque necorrespondpas avec les migrations d’outils de gestion de contenu qui dépendent de la médiathèque • Le CMS dépend de la médiathèque • Si on ne fait rien, on ne pourra commencer la migration du CMS qu’après la migration de la médiathèque

58. Media Library API Media Library 2 API Old Media New New Media CMS API Client

59. Découplerlesmigrations • Moyens • On fait donc reposer le nouveau BO non pas sur l’ancienne médiathèque, mais sur une APIcrééepourl’occasion • Cette API temporaire est une couchededécouplage entre les deux systèmes • La nouvelle médiathèque exposera une APIsimilaire : lorsqu’elle sera prête, on pourra basculer les médiathèques sur un simple changement de conf • Ainsi, planing de migration du BO et de la médiathèque peuvent rester indépendants

60. Faciliter  l’usagesimultané

61. Faciliterl’usagesimultané • Enjeux • Les utilisateurs doivent pouvoir utiliser lesdeuxBOenparallèle pendant un certain temps, jusqu’à ce que toutes les fonctions soient mitrées • On ne veut pas qu’ils aient à saisirunnouveaumotdepassesur le nouveau BO, ni à chaque bascule d’outil • Il faut donc une connexion transparente à l’un et à l’autre BO (« singlesign- on ») • Problème : impossible d’importerlemotdepasse depuis legacy (il était haché) • L’ancien et le nouveau service utilisent des algorithmesdehashing différents

62. Faciliterl’usagesimultané • Moyens • Lors de l’import, on flague l’utilisateur comme nouveau. Il n’a pas de mot de passe. • Lors de la première connection sur le nouveau BO, on appellel’ancien serviced’authentification avec le mot de passe saisi pour le valider. • Si la réponse est OK, on calcule un nouveauhash avec le nouvel algorithme, qu’on stocke côté new

63. Stratégies Méthodologiques Iln’yapasderaison queçasepassemal Stratégies d’Architecture logicielle Stratégies d’Infrastructure

64. Modeleruneinfra Evolutive

65. Modeleruneinfrastructureévolutive • Enjeux • En début de projet, on n’a qu’une vagueidée de l’infrastructure nécessaire au final - puisque les besoins ne sont eux-mêmes pas définitifs • Comme le système, l’infrastructure va évoluerrapidement au cours du projet (on va ajouter des briques chaque semaine) • Il faut effectuer un premierdéploiementauboutde2semaines - c’est bien plus court que le délai de commande d’un serveur physique • Une architecture SOA rend le développement (et l’hébergement) plus difficile. Il faut démarrerdenombreuxservicespour pouvoir développer

66. DevOps Cloud Puppet DockerCapistrano GaudiVMSOA

67. Modeleruneinfrastructureévolutive • Moyens • La migration continue impose donc un hébergementvirtualisésans la contrainte des machines physiques • L’équipe de développement doit avoir une cultureOPs pour appréhender et agir sur l’infrastructure au fur et à mesure que des besoins émergent. • Les configurations de VMs sont automatisées via un outil d’orchestration, on a choisi Puppet • Pour un certain nombre de service, on automatise le setup et la mise à jour avec Docker, nous avons également testé Gaudi (PAS Vagrant + Puppet). • Lesdéploiementssontautomatisés avec Capistrano • Limites • Puppet est définitivement trop complexe, et nous a fait perdre plus de temps en cas particuliers qu’il ne nous en a fait gagner vs un script shell • Capistrano plante en production à cause de Bower - en cours d’investigation • La recettenesefaitpasencontinu, et retarde chaque mise en production

68. Tolérerlespannes

69. Tolérerlespannes • Enjeux • En deux semaines, difficile de monter une infrastructure redondée, où tous les cas de panne ont été testés • L’exigenceduzérodéfaut en production repousse la date de la première migration, et de toutes les suivantes • Certaines pannes introduisent des tempsd’indisponibilitéde plusieurs heures (restauration de backup, réindexation)

70. KISS Rollback Versionning Undelete Failover Resiliency CI

71. Tolérerlespannes • Moyens • Démarrage sur une infrastructure où l’ensemble des services ne sont pas forcément redondés (KISS de l’infrastructure). S’il y a perte de données, on peut toujours utiliser les scripts d’import pour réimporter. • Chaque migration peut être jouée dans les 2 sens (et donc permettre un rollback) • Lorsqu’on transforme les données, on garde l’ancienne et la nouvelle version. Jackrabbit permet le versionning de contenus, et la fonction de suppression est désactivée au profit d’une fonction de dépublication. • Cela apporte une capacité à se remettre d’un incident (on parle de « résilience ») • L’ancienne plate-forme reste disponible jusqu’à la fin du projet, et sert de plate-forme de repli (failover) • Tout le monde peut déployer en production pour pouvoir corriger rapidement un bug • L’intégration continue est obligatoire pour valider la non-régression, notamment via des tests fonctionnels fournis • Limites • Ascenseur émotionnel • Il faut maitriser les craintes des équipe de casser le système en déployant un bug

72. Echantillonner Laproduction

73. Echantillonnerlaproduction • Enjeux • Certains cas d’erreur n’apparaissent qu’avec des données réelles (ex: perf avec 800 000 contenus), ou avec des utilisateurs réel • Les POs ne connaissent pas tous les cas limites • Il faut donc pouvoir tester en production

74. Feature  Flag Bucket  Testing Betatesters Measure ESI Sentry SEO %

75. Echantillonnerlaproduction • Moyens • Activation des ESI sur un sous-ensemble de contenus (25%), avec un modulo d’id pour éviter un biais d’échantillonnage • Utilisation de Feature flags pour n’activer les fonctionnalités que pour un groupe d’utilisateurs • Utiliser l’équipe pilote comme beta testeurs tout au long du projet • Mesurer tout, et si possible comparer automatiquement les métriques avant et après déploiement • Métriques système pour valider la performance (CPU, mémoire, etc) • Remontée d’erreur automatique (avec Sentry) pour les erreurs serveur ET client • Compter les contenus différents pour détecter problèmes • Métriques métier pour valider usage • Métriques Xiti pour mesurer impact SEO

76. Conclusion

77. Commencezlamigrationcontinue dèsmaintenant

78. Conclusion:c’estpossible • La migration de 20 Minutes est toujoursencours. • On ne sait pas encore si c’est un succès. Mais grâce à la migration continue, on a déjà évitél’échec plusieurs fois. • La migration continue permet donc derefondreunsystèmeinformatiquedefaçonagile. • Mais la migration continue sert bien au-delà des projets de refonte. Parce qu’avec la gestion de produit agile, onrefondunprojetdèslesecondsprint. Et on refond à chaque sprint suivant. On revient plusieurs fois sur chaque composant en fonction des retours d’utilisation. • Les préceptes de la migration continue sont donc valables pourlesrefontescommepourlesnouveauxprojets. • On a tous, dans la vie, une migration qui nous attend. Ne la faites pas attendre. Commencez à migrer vos données, vos utilisateurs, vos fonctionnalités dès maintenant. Pas besoin de refonte. La migration continue vous permettra de réduire les risques, de réduire le stress. • La migration continue vous permettra de mettre en ligne, tout simplement.

79. Merci FrançoisZaninotto @francoisz marmelabrecrute  surNancyetParis Simon @SIm07 20Minutes

La migration continue vers Symfony

Francois Zaninotto

La migration continue vers Symfony