La migration continue vers Symfony

François Zaninotto - Simon Rolland

L’agilité sans feuille blanche

Simon RollandChef de projet Technique 20 Minutes #php #medias @SIm07

François ZaninottoCEO marmelab

Symfony doc - Propel - Faker - Gremlins.js #agile #symfony #js

@francoiszné le 8 avril 1974

Stratégies d’Architecture

logicielle

Stratégies d’Infrastructure

Stratégies Méthodologiques

Il n’y a pas de raison que ça se passe mal

La refonte 20 Minutes

en chiffres

3ème site de news, premier quotidien d’info papier 90 millions de pages vues sue le web (source OJD juillet 2013)

106 millions de pages vues sur mobiles et tablettes (source OJD Mobile juillet 2013)

120 rédacteurs utilisent le système en 24/7 800 000 articles à migrer 1 400 000 lignes de code à migrer (PHP + Symfony 1.2) 6 mois de délai

Objectif Etna

Objectif Etna• Etna est le CMS de marmelab. • A nous tous, on a développé près d’une demi-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ôt documentaire (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

La migration : une formalité ?

La migration : une formalité ?

• 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, à la fin 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.

ATTENTION'CE'FLIM'S’INSPIRE'DE'FAITS'REELS

MERCI'DE'VOTRE'COMPREHENSION

Neverending StoryScénario catastrophe n°1

Scénario catastrophe #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’applications pas du tout prioritaires. 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 la dernière application (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.

L’ancien système Ne sera jamais éteint

Leçon n°1

Leçon n°1 L’ancien système ne sera jamais éteint

• Ne pas mettre l’extinction de l’ancien système soit sur le chemin critique

• Trouver des moyens de migrer des portions d’applications

• Trouver des moyens de ne pas migrer les applications on prioritaires

• Prioriser les migrations selon la valeur business

Scénario catastrophe n°2

John Carter

Scénario catastrophe #2• Les limites du système actuel résident surtout dans un modèle de données devenu inadapté

• La refonte consiste donc en une réécriture des couches basses, 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 aucun changement pendant 6 mois

• 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 fois un gouffre et un four

Pas de migration sans valeur métier

Leçon n°2

Leçon n°2 Pas de migration sans valeur métier

• Impliquer les utilisateurs très en amont pour comprendre leurs vrais besoins

• Mêler migration technique et évolutions

• Mettre en production 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éfice utilisateur

Scénario catastrophe n°3Pokemon XVI

Scénario catastrophe #3• Pour le nouveau système, on conçoit un modèle de donné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 cas particuliers 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 modifications seront perdues 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

Les migrations de données sont coeur

Leçon n°3

Leçon n°3 Les migrations de données sont coeur

• Ne pas attendre la fin du projet pour développer les migrations.

• Les données initiales sont toujours en mauvais é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).

• Tester unitairement les imports / export

• Comparer les pages générées par l’ancien et le nouveau système pour valider la boucle d’import / export (legacy => new => legacy)

• Trouver des mécanismes de mise à jour non bloquants / asynchrones pour ne pas empêcher l’utilisation du CMS pendant un réimporte / réexport (cron, AMQP)

La Migration Ancien système Nouveau systèmeAncien système

Bouton rouge

La migration « bouton rouge »• Tous ces scénarios catastrophe partent de la même erreur initiale. La migration y est

vue comme un évènement ponctuel, 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 ça fait mal, faites-le plus souvent ». 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 « migration continue » - les anglos-saxons parlent d’incremental migration.

La Migration

Continue

La migration continue

• 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.

Stratégies d’Infrastructure

Il n’y a pas de raison que ça se passe mal

Stratégies d’Architecture

logicielle

Stratégies Méthodologiques

Migrer à chaque

Itération

Migrer par ité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 cycle projet 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

Migrate Measure

Learn

Migrer par itérations• Une première migration ASAP, dans l’idéal dès la troisième semaine (en pratique, au bout de 3 mois)

• Au moins une migration toutes les 2 semaines, 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 niveau de risque : 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 Lean Startup : 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)

AssocierLe métier

Associer le mé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 pratiques mé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ésistance au changement • Apprendre sans trop passer de temps en formation (ou sans attendre une formation,

qui doit être planifiée) • Minimiser le temps passé à 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)

Perso

nas

TrainSell Early

Adopters

Communicate

PilotAd

apt

Participate

Associer le mé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. • Donner envie à 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 bouton de feedback 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 prioriser les bugfixes dès la seconde itération • Former en continu aux nouveautés

Faire sentir Le changement

Faire sentir le changement

• Une migration d’un SI coeur de métier est un projet d’entreprise. Toute l’entreprise doit y être associée • Enjeux

• Les utilisateurs doivent donner leur confiance à un outil pas finalisé • les utilisateurs doivent sentir que leurs retours sont pris en compte pour continuer à en donner • la DSI doit voir les choses avancer alors même qu’on n’a pas de vision globale exacte (problème

inhérent à l’agilité) • Il faut des changements visibles à chaque itération

• Moyens • Etre très réactif sur la correction de bug, donc prioriser les bugfixes 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 pourcentage de l’ancien SI migré

Faire sentir le changement

• Pour visualiser l’avancement de la migration 20 Minutes, on a commencé par cartographier l’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 vecteur de communication du changement.

Stratégies d’Infrastructure

Stratégies Méthodologiques

Il n’y a pas de raison que ça se passe mal

Stratégies d’Architecture

logicielle

Découper en

Services

Découper en services

• 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

AMQP SOA

InterfaceRE

ST StandardHTTPMicroservices

Guzzle RabbitMQ

Découper en services• 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

Synchroniser Les persistences

Legacy New

Synchroniser les persistences• 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ées dans 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) • Pas de modification de donnée possible côté Legacy

Synchroniser les persistences• 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 unit testé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

Supprimer les Couplages

1001 1003 10051002 1004 1006

Supprimer les couplages• Enjeux

• Des fonctionnalités du nouveau BO nécessitent un identifiant de contenu venant de legacy (ex: contenus liés)

• Legacy utilise une séquence MYSQL autoincré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éer des Legacy Id • Mais il faut éviter les conflits (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 moteur de génération d’id transactionnel côté New (Jackrabbit, pas MySQL)

Supprimer les couplages

• Moyens

• On utilise des incréments d’index de 2 en 2 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 Service de sé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

Migrer les pagespar blocs

Migrer les pages par blocs

• Enjeux

• Les pages d’un CMS contiennent beaucoup d’é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 trop long

Header

Article

Footer

Pub

Tags

Local

Legacy New

Header

Article

Footer

Pub

Tags

Local

Header

Article

Footer

Pub

Tags

Local

Legacy New

Legacy New

Header

Article

Footer

Pub

Tags

Local

Header

Article

Footer

Pub

Tags

Local

Header

Article

Footer

Pub

Tags

Local

Migrer les pages par blocs• Moyens

• Recomposer une page à partir de backends différents : SSI (non), ESI (facile avec SF2), Ajax

• Migrer les blocs un par un, en vérifiant que tout ce passe bien (notamment niveau performance)

• Regrouper les ESI une fois migré un ensemble cohérent (ex = Titre + chapo + Body = Article)

• Utiliser un reverse proxy qui aiguille les requêtes internes (et les protège d’un accès extérieur)

• Migrer le contrôleur de pages en dernier, quand tous les éléments de page sont migrés (à moins de pouvoir inclure un ESI sur Legacy…)

• Limite

• La refonte graphique, qui ne sait pas se faire de façon continue

Découpler les migrations

Découpler les migrations• 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 ne correspond pas 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

Media Library AP

I Media Library 2AP

I

Old Media New New

Media

CMS

API Client

Découpler les migrations• Moyens

• On fait donc reposer le nouveau BO non pas sur l’ancienne médiathèque, mais sur une API créée pour l’occasion

• Cette API temporaire est une couche de découplage entre les deux systèmes

• La nouvelle médiathèque exposera une API similaire : 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

Faciliterl’usage simultané

Faciliter l’usage simultané• Enjeux

• Les utilisateurs doivent pouvoir utiliser les deux BO en parallèle pendant un certain temps, jusqu’à ce que toutes les fonctions soient mitrées

• On ne veut pas qu’ils aient à saisir un nouveau mot de passe sur le nouveau BO, ni à chaque bascule d’outil

• Il faut donc une connexion transparente à l’un et à l’autre BO (« single sign-on »)

• Problème : impossible d’importer le mot de passe depuis legacy (il était haché)

• L’ancien et le nouveau service utilisent des algorithmes de hashing différents

Faciliter l’usage simultané

• 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 appelle l’ancien

service d’authentification avec le mot de passe saisi pour le valider. • Si la réponse est OK, on calcule un nouveau hash avec le nouvel

algorithme, qu’on stocke côté new

Stratégies Méthodologiques

Il n’y a pas de raison que ça se passe mal

Stratégies d’Architecture

logicielle

Stratégies d’Infrastructure

Modeler une infra

Evolutive

Modeler une infrastructure évolutive• Enjeux

• En début de projet, on n’a qu’une vague idé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 évoluer rapidement au cours du projet (on va ajouter des briques chaque semaine)

• Il faut effectuer un premier déploiement au bout de 2 semaines - 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émarrer de nombreux services pour pouvoir développer

DevO

ps CloudPuppet

DockerCapistrano

GaudiVM SOA

Modeler une infrastructure évolutive• Moyens

• La migration continue impose donc un hébergement virtualisé sans la contrainte des machines physiques • L’équipe de développement doit avoir une culture OPs 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). • Les déploiements sont automatisé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 recette ne se fait pas en continu, et retarde chaque mise en production

Tolérer les pannes

Tolérer les pannes

• Enjeux • En deux semaines, difficile de monter une infrastructure redondée, où

tous les cas de panne ont été testés • L’exigence du zéro défaut en production repousse la date de la première

migration, et de toutes les suivantes • Certaines pannes introduisent des temps d’indisponibilité de plusieurs

heures (restauration de backup, réindexation)

KISS

Rollback

VersionningUndelete

Failover

ResiliencyCI

Tolérer les pannes• 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

Echantillonner La production

Echantillonner la production

• 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

Feature FlagBucket

Testing

Beta

teste

rs

Measure

ESISentrySEO

%

Echantillonner la production• 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

Conclusion

Commencez la migration continue

dès maintenant

Conclusion : c’est possible• La migration de 20 Minutes est toujours en cours.

• 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 de refondre un système informatique de façon agile.

• Mais la migration continue sert bien au-delà des projets de refonte. Parce qu’avec la gestion de produit agile, on refond un projet dès le second sprint. 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 pour les refontes comme pour les nouveaux projets.

• 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.

MerciFrançois Zaninotto

@francoisz marmelab recrute sur Nancy et Paris

Simon @SIm07

20 Minutes