La migration continue vers Symfony
12 j'aime9,065 vues
Le document traite de la migration d'un CMS vers Symfony, en soulignant les défis et les leçons tirées, notamment la nécessité d'une migration continue plutôt qu'un gros transfert unique. Il décrit plusieurs scénarios catastrophes liés aux migrations ratées et fournit des stratégies pour assurer une migration réussie tout en impliquant les utilisateurs et en adoptant des approches agiles. La fin du document évoque l'importance de découper les systèmes en services et de synchroniser les données entre l'ancien et le nouveau système.
La migration continue vers Symfony
- 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
- 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.
- 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.
- 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
- 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
- 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
- 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
- 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.
- 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.
- 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
- 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)
- 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)
- 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
- 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é
- 39. 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.
- 42. 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
- 44. 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
- 46. 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
- 49. 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
- 51. 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)
- 53. 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
- 55. 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
- 59. 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
- 61. 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
- 63. 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
- 65. 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
- 68. 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
- 71. 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
- 73. 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
- 74. Tolérerlespannes
- 75. 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)
- 77. 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
- 79. 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
- 81. 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
- 82. Conclusion
- 84. 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.