SlideShare une entreprise Scribd logo
1  sur  85
Télécharger pour lire hors ligne
Lamigrationcontinue
versSymfony
FrançoisZaninotto-SimonRolland
L’agilitésansfeuilleblanche
SimonRolland
ChefdeprojetTechnique20Minutes
#php#medias
@SIm07
FrançoisZaninotto
CEOmarmelab
Symfonydoc-Propel -Faker-Gremlins.js
#agile#symfony#js
@francoisz
néle8avril1974
Stratégies
d’Architecture
logicielle
Stratégies
d’Infrastructure
Stratégies
Méthodologiques
Iln’yapasderaison
queçasepassemal
Larefonte20Minutes
enchiffres
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
ObjectifEtna
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
Lamigration:
uneformalité?
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.
ATTENTION'
CE'FLIM'S’INSPIRE'
DE'FAITS'REELS
MERCI'DE'VOTRE'
COMPREHENSION
NeverendingStory
Scénariocatastrophen°1
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.
L’anciensystème
Neserajamaiséteint
Leçonn°1
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
Scénariocatastrophen°2
JohnCarter
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
Pasdemigration
sansvaleurmétier
Leçonn°2
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
Scénariocatastrophen°3
PokemonXVI
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
Lesmigrationsde
donnéessontcoeur
Leçonn°3
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)
LaMigration
Ancien système Nouveau systèmeAncien système
Boutonrouge
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.
LaMigration
Continue
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.
Stratégies
d’Infrastructure
Iln’yapasderaison
queçasepassemal
Stratégies
d’Architecture
logicielle
Stratégies
Méthodologiques
Migreràchaque
Itération
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
Migrate
Measure
Learn
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)
Associer

Le métier
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)
Personas
Train
Sell Early
Adopters
Communicate
PilotAdapt
Participate
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
FairesentirLechangement
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é
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.
Stratégies
d’Infrastructure
Stratégies
Méthodologiques
Iln’yapasderaison
queçasepassemal
Stratégies
d’Architecture
logicielle
Découperen
Services
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
AMQP
SOA
InterfaceRESTStandardHTTP
Microservices
Guzzle
RabbitMQ
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
Synchroniser
Lespersistences
Legacy New
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
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
Supprimerles

Couplages
1001
1003
1005
1002
1004
1006
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)
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
Migrerlespages

parblocs
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
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
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
Découpler

lesmigrations
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
Media
Library
API
Media
Library 2
API
Old
Media
New
New
Media
CMS
API Client
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
Faciliter

l’usagesimultané
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
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
Stratégies
Méthodologiques
Iln’yapasderaison
queçasepassemal
Stratégies
d’Architecture
logicielle
Stratégies
d’Infrastructure
Modeleruneinfra
Evolutive
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
DevOps
Cloud
Puppet
DockerCapistrano
GaudiVMSOA
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
Tolérerlespannes
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)
KISS
Rollback
Versionning
Undelete
Failover
Resiliency
CI
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
Echantillonner
Laproduction
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
Feature

Flag
Bucket

Testing
Betatesters
Measure
ESI
Sentry
SEO
%
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
Conclusion
Commencezlamigrationcontinue
dèsmaintenant
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.
Merci
FrançoisZaninotto
@francoisz
marmelabrecrute

surNancyetParis
Simon
@SIm07
20Minutes

Contenu connexe

Tendances (11)

Ataxia
AtaxiaAtaxia
Ataxia
 
Caderno tecnico 82 medicina de felino
Caderno tecnico 82 medicina de felinoCaderno tecnico 82 medicina de felino
Caderno tecnico 82 medicina de felino
 
Biologia e controle de serpentes peçonhentas
Biologia e controle de serpentes peçonhentasBiologia e controle de serpentes peçonhentas
Biologia e controle de serpentes peçonhentas
 
Aula Figado
Aula FigadoAula Figado
Aula Figado
 
Radiografia de tórax aula2-padrãoacinar-intersticial
Radiografia de tórax   aula2-padrãoacinar-intersticialRadiografia de tórax   aula2-padrãoacinar-intersticial
Radiografia de tórax aula2-padrãoacinar-intersticial
 
Sindromes medularesmedicina
Sindromes medularesmedicinaSindromes medularesmedicina
Sindromes medularesmedicina
 
Guia de identificação - pelos de mamíferos brasileiros
Guia de identificação - pelos de mamíferos brasileirosGuia de identificação - pelos de mamíferos brasileiros
Guia de identificação - pelos de mamíferos brasileiros
 
Měření otoakustických emisí
Měření otoakustických emisíMěření otoakustických emisí
Měření otoakustických emisí
 
Acessos anteriores aos ventrículos laterais
Acessos anteriores aos ventrículos lateraisAcessos anteriores aos ventrículos laterais
Acessos anteriores aos ventrículos laterais
 
Nós Cirúrgicos
Nós CirúrgicosNós Cirúrgicos
Nós Cirúrgicos
 
Bioterismo
BioterismoBioterismo
Bioterismo
 

En vedette

Il était une fois le Continuous Delivery chez Meetic
Il était une fois le Continuous Delivery chez MeeticIl était une fois le Continuous Delivery chez Meetic
Il était une fois le Continuous Delivery chez MeeticJoris Calabrese
 
Comment construire un environnement e-commerce complet avec Symfony 2 ?
Comment construire un environnement e-commerce complet avec Symfony 2 ? Comment construire un environnement e-commerce complet avec Symfony 2 ?
Comment construire un environnement e-commerce complet avec Symfony 2 ? Fabien Gasser
 
Symfony live Paris 2014 - Symfony2 sur Azure
Symfony live Paris 2014 - Symfony2 sur AzureSymfony live Paris 2014 - Symfony2 sur Azure
Symfony live Paris 2014 - Symfony2 sur AzureStéphane ESCANDELL
 
Very lastroom symfony1 vers symfony2 en douceur
Very lastroom   symfony1 vers symfony2 en douceurVery lastroom   symfony1 vers symfony2 en douceur
Very lastroom symfony1 vers symfony2 en douceurSébastien Houzé
 
Modernisation of legacy PHP applications using Symfony2 - PHP Northeast Confe...
Modernisation of legacy PHP applications using Symfony2 - PHP Northeast Confe...Modernisation of legacy PHP applications using Symfony2 - PHP Northeast Confe...
Modernisation of legacy PHP applications using Symfony2 - PHP Northeast Confe...Fabrice Bernhard
 
Presentation Symfony2
Presentation Symfony2Presentation Symfony2
Presentation Symfony2Ahmed ABATAL
 
Meetup scala paris user group - conflation like @ meetic
Meetup scala paris user group - conflation like @ meeticMeetup scala paris user group - conflation like @ meetic
Meetup scala paris user group - conflation like @ meeticmeeticTech
 
Modernisation of Legacy PHP Applications to Symfony2 - Symfony Live Berlin 2012
Modernisation of Legacy PHP Applications to Symfony2 - Symfony Live Berlin 2012Modernisation of Legacy PHP Applications to Symfony2 - Symfony Live Berlin 2012
Modernisation of Legacy PHP Applications to Symfony2 - Symfony Live Berlin 2012Fabrice Bernhard
 
Migrating to Symfony 3.0
Migrating to Symfony 3.0Migrating to Symfony 3.0
Migrating to Symfony 3.0nicolas.grekas
 
REX sur l'outilage Continuous Delivery
REX sur l'outilage Continuous DeliveryREX sur l'outilage Continuous Delivery
REX sur l'outilage Continuous DeliveryDamien Goldenberg
 
Symfony2: 30 astuces et bonnes pratiques
Symfony2: 30 astuces et bonnes pratiquesSymfony2: 30 astuces et bonnes pratiques
Symfony2: 30 astuces et bonnes pratiquesNoel GUILBERT
 
Audit technique de code
Audit technique de codeAudit technique de code
Audit technique de codeMehdi TAZI
 
Private Rented Communities by urbanbubble
Private Rented Communities by urbanbubblePrivate Rented Communities by urbanbubble
Private Rented Communities by urbanbubbleFarah Bahsoon, MSc
 
Creating hypermedia APIs in a few minutes using the API Platform framework
Creating hypermedia APIs in a few minutes using the API Platform frameworkCreating hypermedia APIs in a few minutes using the API Platform framework
Creating hypermedia APIs in a few minutes using the API Platform frameworkLes-Tilleuls.coop
 
Le pattern View Model avec Symfony2
Le pattern View Model avec Symfony2Le pattern View Model avec Symfony2
Le pattern View Model avec Symfony2RomainKuzniak
 
Space Apps Montreal
Space Apps MontrealSpace Apps Montreal
Space Apps Montrealheri
 

En vedette (20)

Il était une fois le Continuous Delivery chez Meetic
Il était une fois le Continuous Delivery chez MeeticIl était une fois le Continuous Delivery chez Meetic
Il était une fois le Continuous Delivery chez Meetic
 
Comment construire un environnement e-commerce complet avec Symfony 2 ?
Comment construire un environnement e-commerce complet avec Symfony 2 ? Comment construire un environnement e-commerce complet avec Symfony 2 ?
Comment construire un environnement e-commerce complet avec Symfony 2 ?
 
Symfony live Paris 2014 - Symfony2 sur Azure
Symfony live Paris 2014 - Symfony2 sur AzureSymfony live Paris 2014 - Symfony2 sur Azure
Symfony live Paris 2014 - Symfony2 sur Azure
 
Very lastroom symfony1 vers symfony2 en douceur
Very lastroom   symfony1 vers symfony2 en douceurVery lastroom   symfony1 vers symfony2 en douceur
Very lastroom symfony1 vers symfony2 en douceur
 
Symfony à la télé
Symfony à la téléSymfony à la télé
Symfony à la télé
 
Modernisation of legacy PHP applications using Symfony2 - PHP Northeast Confe...
Modernisation of legacy PHP applications using Symfony2 - PHP Northeast Confe...Modernisation of legacy PHP applications using Symfony2 - PHP Northeast Confe...
Modernisation of legacy PHP applications using Symfony2 - PHP Northeast Confe...
 
Presentation Symfony2
Presentation Symfony2Presentation Symfony2
Presentation Symfony2
 
Meetup scala paris user group - conflation like @ meetic
Meetup scala paris user group - conflation like @ meeticMeetup scala paris user group - conflation like @ meetic
Meetup scala paris user group - conflation like @ meetic
 
Modernisation of Legacy PHP Applications to Symfony2 - Symfony Live Berlin 2012
Modernisation of Legacy PHP Applications to Symfony2 - Symfony Live Berlin 2012Modernisation of Legacy PHP Applications to Symfony2 - Symfony Live Berlin 2012
Modernisation of Legacy PHP Applications to Symfony2 - Symfony Live Berlin 2012
 
Migrating to Symfony 3.0
Migrating to Symfony 3.0Migrating to Symfony 3.0
Migrating to Symfony 3.0
 
REX sur l'outilage Continuous Delivery
REX sur l'outilage Continuous DeliveryREX sur l'outilage Continuous Delivery
REX sur l'outilage Continuous Delivery
 
Symfony2: 30 astuces et bonnes pratiques
Symfony2: 30 astuces et bonnes pratiquesSymfony2: 30 astuces et bonnes pratiques
Symfony2: 30 astuces et bonnes pratiques
 
Audit technique de code
Audit technique de codeAudit technique de code
Audit technique de code
 
Private Rented Communities by urbanbubble
Private Rented Communities by urbanbubblePrivate Rented Communities by urbanbubble
Private Rented Communities by urbanbubble
 
Creating hypermedia APIs in a few minutes using the API Platform framework
Creating hypermedia APIs in a few minutes using the API Platform frameworkCreating hypermedia APIs in a few minutes using the API Platform framework
Creating hypermedia APIs in a few minutes using the API Platform framework
 
Le pattern View Model avec Symfony2
Le pattern View Model avec Symfony2Le pattern View Model avec Symfony2
Le pattern View Model avec Symfony2
 
DevOps
DevOpsDevOps
DevOps
 
Introducing DevOps
Introducing DevOpsIntroducing DevOps
Introducing DevOps
 
Space Apps Montreal
Space Apps MontrealSpace Apps Montreal
Space Apps Montreal
 
Nouveaux Outils
Nouveaux OutilsNouveaux Outils
Nouveaux Outils
 

Similaire à La migration continue vers Symfony

L’informatique efficience
L’informatique efficienceL’informatique efficience
L’informatique efficienceMichel Bruchet
 
Des poneys à Liberation.fr
Des poneys à Liberation.frDes poneys à Liberation.fr
Des poneys à Liberation.frliberation_dev
 
Le Comptoir OCTO - Accelerate @Cdiscount
Le Comptoir OCTO - Accelerate @CdiscountLe Comptoir OCTO - Accelerate @Cdiscount
Le Comptoir OCTO - Accelerate @CdiscountOCTO Technology
 
AES22-A la découverte d'Accelerate.pdf
AES22-A la découverte d'Accelerate.pdfAES22-A la découverte d'Accelerate.pdf
AES22-A la découverte d'Accelerate.pdfAgile En Seine
 
REX - Passage de CVS à Git
REX - Passage de CVS à GitREX - Passage de CVS à Git
REX - Passage de CVS à GitPierre Templier
 
Eco Conception logicielle : Comment réduire par deux la consommation d’...
Eco Conception logicielle : Comment réduire par deux la consommation d’...Eco Conception logicielle : Comment réduire par deux la consommation d’...
Eco Conception logicielle : Comment réduire par deux la consommation d’...Microsoft
 
BIG DATA - Cloud Computing
BIG DATA - Cloud ComputingBIG DATA - Cloud Computing
BIG DATA - Cloud Computingsenejug
 
Bizarre... vous avez dit bizarre - Paris Monitoring meetup #2
Bizarre... vous avez dit bizarre - Paris Monitoring meetup #2Bizarre... vous avez dit bizarre - Paris Monitoring meetup #2
Bizarre... vous avez dit bizarre - Paris Monitoring meetup #2Paris Monitoring
 
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?Drupagora 2013 : Drupal8 et Symfony2, quel impact ?
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?ekino
 
Accélérez itSMF 2013
Accélérez itSMF 2013Accélérez itSMF 2013
Accélérez itSMF 2013itSMF France
 
📝 ✅ La checklist ultime pour rendre vos applications cloud native
📝 ✅ La checklist ultime pour rendre vos applications cloud native 📝 ✅ La checklist ultime pour rendre vos applications cloud native
📝 ✅ La checklist ultime pour rendre vos applications cloud native KatiaHIMEUR1
 
Presentation Rex Methodes Agiles
Presentation Rex Methodes AgilesPresentation Rex Methodes Agiles
Presentation Rex Methodes AgilesIppon
 
SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011Christophe NEY
 
Méthodes agiles, frameworks javascript: optimisez votre time to market
Méthodes agiles, frameworks javascript: optimisez votre time to marketMéthodes agiles, frameworks javascript: optimisez votre time to market
Méthodes agiles, frameworks javascript: optimisez votre time to marketmichael_bailly
 
L'intégration continue chez Pages Jaunes - Build Bot Mobile
L'intégration continue chez Pages Jaunes - Build Bot MobileL'intégration continue chez Pages Jaunes - Build Bot Mobile
L'intégration continue chez Pages Jaunes - Build Bot MobileCocoaHeads France
 
Comment passer d'un POC en prod @ plusieurs milliards de rêquetes
Comment passer d'un POC en prod @ plusieurs milliards de rêquetesComment passer d'un POC en prod @ plusieurs milliards de rêquetes
Comment passer d'un POC en prod @ plusieurs milliards de rêquetesCarles Sistare
 
Optimisations et Performances d'un POC en prod @ plusieurs milliards de requê...
Optimisations et Performances d'un POC en prod @ plusieurs milliards de requê...Optimisations et Performances d'un POC en prod @ plusieurs milliards de requê...
Optimisations et Performances d'un POC en prod @ plusieurs milliards de requê...David Caramelo
 
Php forum 2017 - Maisons du Monde
Php forum 2017 - Maisons du MondePhp forum 2017 - Maisons du Monde
Php forum 2017 - Maisons du Mondemarchugon
 
Processus d’intégration continue et outils
Processus d’intégration continue et outilsProcessus d’intégration continue et outils
Processus d’intégration continue et outilsAgile Tour 2009 Québec
 

Similaire à La migration continue vers Symfony (20)

L’informatique efficience
L’informatique efficienceL’informatique efficience
L’informatique efficience
 
Des poneys à Liberation.fr
Des poneys à Liberation.frDes poneys à Liberation.fr
Des poneys à Liberation.fr
 
Le Comptoir OCTO - Accelerate @Cdiscount
Le Comptoir OCTO - Accelerate @CdiscountLe Comptoir OCTO - Accelerate @Cdiscount
Le Comptoir OCTO - Accelerate @Cdiscount
 
AES22-A la découverte d'Accelerate.pdf
AES22-A la découverte d'Accelerate.pdfAES22-A la découverte d'Accelerate.pdf
AES22-A la découverte d'Accelerate.pdf
 
REX - Passage de CVS à Git
REX - Passage de CVS à GitREX - Passage de CVS à Git
REX - Passage de CVS à Git
 
Eco Conception logicielle : Comment réduire par deux la consommation d’...
Eco Conception logicielle : Comment réduire par deux la consommation d’...Eco Conception logicielle : Comment réduire par deux la consommation d’...
Eco Conception logicielle : Comment réduire par deux la consommation d’...
 
BIG DATA - Cloud Computing
BIG DATA - Cloud ComputingBIG DATA - Cloud Computing
BIG DATA - Cloud Computing
 
Bizarre... vous avez dit bizarre - Paris Monitoring meetup #2
Bizarre... vous avez dit bizarre - Paris Monitoring meetup #2Bizarre... vous avez dit bizarre - Paris Monitoring meetup #2
Bizarre... vous avez dit bizarre - Paris Monitoring meetup #2
 
Juste à temps (Just in time)
Juste à temps (Just in time)Juste à temps (Just in time)
Juste à temps (Just in time)
 
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?Drupagora 2013 : Drupal8 et Symfony2, quel impact ?
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?
 
Accélérez itSMF 2013
Accélérez itSMF 2013Accélérez itSMF 2013
Accélérez itSMF 2013
 
📝 ✅ La checklist ultime pour rendre vos applications cloud native
📝 ✅ La checklist ultime pour rendre vos applications cloud native 📝 ✅ La checklist ultime pour rendre vos applications cloud native
📝 ✅ La checklist ultime pour rendre vos applications cloud native
 
Presentation Rex Methodes Agiles
Presentation Rex Methodes AgilesPresentation Rex Methodes Agiles
Presentation Rex Methodes Agiles
 
SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011
 
Méthodes agiles, frameworks javascript: optimisez votre time to market
Méthodes agiles, frameworks javascript: optimisez votre time to marketMéthodes agiles, frameworks javascript: optimisez votre time to market
Méthodes agiles, frameworks javascript: optimisez votre time to market
 
L'intégration continue chez Pages Jaunes - Build Bot Mobile
L'intégration continue chez Pages Jaunes - Build Bot MobileL'intégration continue chez Pages Jaunes - Build Bot Mobile
L'intégration continue chez Pages Jaunes - Build Bot Mobile
 
Comment passer d'un POC en prod @ plusieurs milliards de rêquetes
Comment passer d'un POC en prod @ plusieurs milliards de rêquetesComment passer d'un POC en prod @ plusieurs milliards de rêquetes
Comment passer d'un POC en prod @ plusieurs milliards de rêquetes
 
Optimisations et Performances d'un POC en prod @ plusieurs milliards de requê...
Optimisations et Performances d'un POC en prod @ plusieurs milliards de requê...Optimisations et Performances d'un POC en prod @ plusieurs milliards de requê...
Optimisations et Performances d'un POC en prod @ plusieurs milliards de requê...
 
Php forum 2017 - Maisons du Monde
Php forum 2017 - Maisons du MondePhp forum 2017 - Maisons du Monde
Php forum 2017 - Maisons du Monde
 
Processus d’intégration continue et outils
Processus d’intégration continue et outilsProcessus d’intégration continue et outils
Processus d’intégration continue et outils
 

Plus de Francois Zaninotto

Vous aimez les legos ? React est fait pour vous !
Vous aimez les legos ? React est fait pour vous !Vous aimez les legos ? React est fait pour vous !
Vous aimez les legos ? React est fait pour vous !Francois Zaninotto
 
La blockchain, quand l'individu sert au collectif... malgré lui
La blockchain, quand l'individu sert au collectif... malgré luiLa blockchain, quand l'individu sert au collectif... malgré lui
La blockchain, quand l'individu sert au collectif... malgré luiFrancois Zaninotto
 
Le jeu vidéo à la rescousse du web
Le jeu vidéo à la rescousse du webLe jeu vidéo à la rescousse du web
Le jeu vidéo à la rescousse du webFrancois Zaninotto
 
Frameworks : A history of violence
Frameworks : A history of violenceFrameworks : A history of violence
Frameworks : A history of violenceFrancois Zaninotto
 
La programmation asynchrone... et les pates
La programmation asynchrone... et les patesLa programmation asynchrone... et les pates
La programmation asynchrone... et les patesFrancois Zaninotto
 
Bonnes pratiques de développement avec Node js
Bonnes pratiques de développement avec Node jsBonnes pratiques de développement avec Node js
Bonnes pratiques de développement avec Node jsFrancois Zaninotto
 
Simplify your professional web development with symfony
Simplify your professional web development with symfonySimplify your professional web development with symfony
Simplify your professional web development with symfonyFrancois Zaninotto
 

Plus de Francois Zaninotto (12)

Vous aimez les legos ? React est fait pour vous !
Vous aimez les legos ? React est fait pour vous !Vous aimez les legos ? React est fait pour vous !
Vous aimez les legos ? React est fait pour vous !
 
GraphQL, l'avenir du REST ?
GraphQL, l'avenir du REST ?GraphQL, l'avenir du REST ?
GraphQL, l'avenir du REST ?
 
La blockchain, quand l'individu sert au collectif... malgré lui
La blockchain, quand l'individu sert au collectif... malgré luiLa blockchain, quand l'individu sert au collectif... malgré lui
La blockchain, quand l'individu sert au collectif... malgré lui
 
Le jeu vidéo à la rescousse du web
Le jeu vidéo à la rescousse du webLe jeu vidéo à la rescousse du web
Le jeu vidéo à la rescousse du web
 
Frameworks : A history of violence
Frameworks : A history of violenceFrameworks : A history of violence
Frameworks : A history of violence
 
Php 100k
Php 100kPhp 100k
Php 100k
 
La programmation asynchrone... et les pates
La programmation asynchrone... et les patesLa programmation asynchrone... et les pates
La programmation asynchrone... et les pates
 
Bonnes pratiques de développement avec Node js
Bonnes pratiques de développement avec Node jsBonnes pratiques de développement avec Node js
Bonnes pratiques de développement avec Node js
 
Ce bon vieux propel
Ce bon vieux propelCe bon vieux propel
Ce bon vieux propel
 
Symfony2 meets propel 1.5
Symfony2 meets propel 1.5Symfony2 meets propel 1.5
Symfony2 meets propel 1.5
 
Developing for Developers
Developing for DevelopersDeveloping for Developers
Developing for Developers
 
Simplify your professional web development with symfony
Simplify your professional web development with symfonySimplify your professional web development with symfony
Simplify your professional web development with symfony
 

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
  • 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é
  • 38.
  • 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
  • 47.
  • 48.
  • 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)
  • 52.
  • 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
  • 66.
  • 67.
  • 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
  • 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
  • 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.