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

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

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

4.
Larefonte20Minutes
enchiffres

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

6.
ObjectifEtna

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

8.
Lamigration:
uneformalité?

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

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

11.
NeverendingStory
Scénariocatastrophen°1

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

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

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

15.
Scénariocatastrophen°2
JohnCarter

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

17.
Pasdemigration
sansvaleurmétier
Leçonn°2

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

19.
Scénariocatastrophen°3
PokemonXVI

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

21.
Lesmigrationsde
donnéessontcoeur
Leçonn°3

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

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

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

25.
LaMigration
Continue

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

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

28.
Migreràchaque
Itération

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

30.
Migrate
Measure
Learn

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

32.
Associer
Le métier

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

34.
Personas
Train
Sell Early
Adopters
Communicate
PilotAdapt
Participate

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

36.
FairesentirLechangement

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

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

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

40.
Découperen
Services

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

42.
AMQP
SOA
InterfaceRESTStandardHTTP
Microservices
Guzzle
RabbitMQ

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

44.
Synchroniser
Lespersistences
Legacy New

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

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

47.
Supprimerles
Couplages
1001
1003
1005
1002
1004
1006

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

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

50.
Migrerlespages
parblocs

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

52.
Header
Article
Footer
Pub
Tags
Local
Legacy New

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

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

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

56.
Découpler
lesmigrations

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

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

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

60.
Faciliter
l’usagesimultané

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

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

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

64.
Modeleruneinfra
Evolutive

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

66.
DevOps
Cloud
Puppet
DockerCapistrano
GaudiVMSOA

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

68.
Tolérerlespannes

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

70.
KISS
Rollback
Versionning
Undelete
Failover
Resiliency
CI

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

72.
Echantillonner
Laproduction

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

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

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

76.
Conclusion

77.
Commencezlamigrationcontinue
dèsmaintenant

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

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