Retrouvez mon speak du PHP Tour 2015, qui a eu lieu à Luxembourg organisé par l'AFUP, autour de la migration de Framework. Dans cette conférence vous apprendrez comment choisir votre nouvel outil et orchestrer sa mise en oeuvre.
29. Presque définitif à cette étape
2 - Le choix
Analyse Choix
Capacity
Planning
L’infra de
prod
Architecture
Migration
progressive
Formation
Premier
projet
30. Aussi nommé « j’évite de vautrer ma prod »
3 - Le capacity planning
Analyse Choix
Capacity
Planning
L’infra de
prod
Architecture
Migration
progressive
Formation
Premier
projet
31.
32. 4 - L’infra de prod
Analyse Choix
Capacity
Planning
L’infra de
prod
Architecture
Migration
progressive
Formation
Premier
projet
33. La checklist
Version de PHP
Extensions
Script de déploiement
Droits en écriture
…
40. 7 - La formation
Analyse Choix
Capacity
Planning
L’infra de
prod
Architecture
Migration
progressive
Formation
Premier
projet
41.
42. Il faut que ça passe, sinon ça casse
8 - Le premier projet
Analyse Choix
Capacity
Planning
Architecture
Migration
progressive
Formation
Premier
projet
Je suis Xavier Leune et aujourd’hui je vais vous parler de la migration de framework et plus précisément de la migration que je mène chez CCM Benchmark Group.
Ca fait désormais 1 an ½ et que je suis responsable framework PHP chez CCM Benchmark Group.
Notre métier chez CCM Benchmark est de créer des sites que nous monétisons via le trafic.
Vous connaissez probablement nos marques les plus fortes :
Journal Des Femmes
Journal Du Net
L’internaute
Copains d’Avant
Comment Ça Marche
Français
Anglais
Allemand
Espagnol
Italien
Polonais
Arabe
Portugais
Neerlandais
Pour un public français mensuel de 21M de Visiteurs Uniques
Notre trafic étant majoritairement à l’étranger, nous nous adressons à 61 M de Visiteurs Uniques chaque mois.
Cela nous place parmi les 1ers groupes français dans le monde.
Aujourd’hui nous sommes engagés dans la migration de notre framework interne vers un outil du marché.
Afin que vous puissiez comprendre le contexte technique dans lequel nous sommes, je vais revenir rapidement sur l’historique du groupe.
Librairie de code interne
+ 250 applications
Une présence francophone
Dette technique très importante
Varnish
Framework interne
Une dette technique plus mesurée
L’expérience du multilingue & l’international
CDN akamai
Un retard à combler chez Benchmark
Une mise à niveau importante pour CCM
L’usage généralisé du framework interne
Poids de la dette technique devenu très important
Il est difficile de maintenir un framework interne, de première génération
Retard technique qui risque de s’accumuler
Code trop fermé, impossibilité d’y intégrer du code tiers, etc.
Démarche ouverte:
reprendre et améliorer l’outil interne ?
Le redévelopper entièrement ?
Choisir un outil existant et migrer vers celui-ci ?
Méthode initialement proposée par Atos Origin
D’autres méthodes existent, semblait la + simple à mettre en œuvre
2 grilles de notation : maturité et technique
Des outils dédiés (compliqués) existent Utilisation d’Excel
Critères identiques pour tous les projets étudiés
17 critères standards
Patrimoine
Age
Historique
Popularité …
Gouvernance
Roadmap
License
Distribution …
Activité
Communauté
Fonctionnalités & bugs
Releases / Versions
Industrialisation
Services
Doc
Méthode qualité
Versionning
Stabilité d’un projet dans le temps
Critères rédigés par le décideur en fonction du type de produit
Chez nous : 28 critères
Bases de données
Drivers dispo
ORM
…
Configuration
Capacité
Format
Tests unitaires
Internationalisation
Cache
Emailing
Queing
Templating
Adéquation entre le projet et les spécificités du demandeur
Logique de l’entonnoir
Choix d’un nombre restreint de projets pour passer à l’étape suivante
Pas le fonctionnement standard de la méthode QSOS mais permet d’aller plus vite
A la fin de cette étape, les projets sélectionnés ne sont pas nécessairement les meilleurs techniquement
On n’en sait rien!!
On veut surtout éviter de choisir un outil qui sera abandonné 6 mois après.
La taille de la communauté ne fait pas la stabilité d’un projet
C’est important de séparer ces 2 notions car une communauté ne dure pas éternellement.
Les gens cessent de supporter une solution si celle-ci n’est plus maintenue correctement ou que la gestion de crise n’est pas au niveau.
Pour illustrer ce propos on peut citer l’exemple de Code Igniter.
Ce framework qui existe depuis 2006 – autant dire la nuit des temps – était maintenu par la société EllisLab.
En juillet 2013, la société a annoncé chercher un repreneur pour le projet.
Il s’est passé 18 mois (décembre 2014) avant que soit annoncé le transfert de gouvernance de Code Igniter au profit du British Columbia Institute of Technology, de Vancouver.
Progès constant de 2007 à 2013
Chute depuis mi 2013
Grille de notation de maturité – issue de Kohana
Grille de notation technique résumée, issue de Kohana
Point important : tests unitaires. Pas le souhait du 100% mais pas judicieux de monter toute une architecture sur un outil pas testé.
Un benchmark n’est PAS un hello world
Comparer des frameworks sur un hello world est aussi intéressant que comparer la capacité de camions à se garer en ville
Définir son cas d’usage – i.e: algo affichage d’une page de forum – le mettre en œuvre et comparer les points de mesure
Si les différences ne permettent pas de conclusion augmenter le cas d’usage et comparer à nouveau
Important : Comparer avec son framework actuel donnée absolue inintéressante, donnée relative primordiale fait on mieux ou moins bien que l’existant
Lors du choix du nouveau framework on n’est pas un expert se faire accompagner par des experts en la question pour optimiser ses performances évite de biaiser le benchmark
Critères de performance déjà en œuvre dans la société
A faire respecter par le nouvel outil
Si aucun des outils choisi ne permet de respecter ce critère vérifier quel composant consomme le plus, débriefer avec l’expert et voir si possible d’améliorer.
A cette étape, on a pu comparer les différents outils sur la maturité du projet,
on a pu étudier en détail leur note technique,
On a pu comparer leurs performances
On a tous les éléments pour faire un choix Bon moment pour évoquer sa préférence personnelle si résultats trop proches
Etape importante mais souvent oubliée benchmark : comparaison perf avec l’actuelle sur 2 points importants : mémoire & temps génération
Extrapolation à l’ensemble des pages pour tirer un coefficient (mémoire / CPU)
Si ratio > 1 nécessité de faire un capacity planning
Mesure de l’état actuel de la prod mémoire consommée par php // Temps CPU consommé
Temps CPU disponible nombre de CPU x Etablir pourcentage consommation actuelle
Projection pour avoir un taux d’usage des machines après migration définir si ça passe ou pas
Toujours travailler avec un ratio favorable et un ratio défavorable. Ca nécessite quelques prérequis :
Mesure consommation de la prod
Application ratio
Comparaison avec les capacités en prod
Définir ses seuils de warning et d’alerte ici 60% warning // 80% critique
Permet un ajustement des capacités de prod, si nécessaire
Une migration de framework N’EST PAS le bon moment pour tout changer
Scripts de déploiement capacité de mettre en œuvre les actions spécifiques ?
Droits d’écriture demandés par le fwk possible ou pas ?
Version de PHP ok ? Extensions nécessaires installées ?
On a TOUS des squelettes dans le placard c’est l’occasion de se rappeler qu’on peut aussi les enterrer
Se faire accompagner Migration de fwk = bonne occasion de remettre à plat certaines archis qui globalement ne sont pas satisfaisantes
Le dernier qui a essayé une migration « Big Bang » a mis 15 Mds d’années à stabiliser à peu près la machine
Il effacera votre passé pour protéger votre avenir
Il ajustera votre passé pour vous permettre d’avoir un avenir
Vert = Infos de debug du nouveau & de l’ancien framework
Rouge = servi par le nouveau framework
Bleu = Le nouveau framework appelle l’ancien pour lui déléguer l’affichage là
Il est important de se faire accompagner d’experts.
Si possible via les éditeurs du framework.
Trop de formateurs auto proclamés font des ravages.
Accorder une attention particulière !
Ce projet sera copié par les autres !
C’est le moment de mettre le paquet, quitte à diminuer son ROI pour ne pas être perdant au global !
Organisation : avoir une personne dédiée à la migration mais qui doit travailler en interaction avec les équipes.
J’ai passé 10mn à vous expliquer comment on privilégie les migrations progressives, maintenant je vous montre le premier big bang qu’on a fait….