Attention Chérie ça va trancher ! #phptour du 12/05/2015

Conférence du 12/05/2015 au #phptour par @etiennesamson et @bastnic.

Sinon, Bastien a publié un livre sur la dette technique, c'est par ici :
http://boutique.letrainde13h37.fr/products/la-dette-technique-bastien-jaillot

Le but de cette conférence est de vous raconter le déroulement d’un an et demi passés sur la refonte des sites Mediapart.

Coté technique, c’est l’histoire d’une migration d’un architecture monolithique inmaintenable à une archi micro service à base de RabbitMQ, Symfony2 et Elasticsearch.

Ce seront des infrastructures que tout le monde connaît, nous allons donc parler de l’état d’esprit des humains qui a amené à la création du monolithe et comment nous avons réussi à inverser la tendance.

Mediapart passe du status de startup à celui d’une PME. Difficulté dans la transformation des métiers de la technique : l’équipe évolue en nombre mais aucun changement d’organisation.

Les développeurs sont dérangés au quotidien par des questions d’informatique interne, comme au sein d’une famille : l’”informaticien” est sollicité pour réparer les imprimantes, installer les logiciels et configure les téléphones.

Sauf que l’équipe est constituée de 4 développeurs Web et d’un DSI, rien à voir avec de l’informatique interne, ce qui les use.

la loi de Conway nous dit que “Tout logiciel reflète l’organisation qui l’a créée”, or nous avons une équipe technique qui est traitée et qui se comporte comme un monolithe.

C’est donc tout naturel qu’elle produit un résultat final rigide et peu évolutif.

Ça entraîne une démotivation, qui pousse à patcher plutôt qu’à fixer le fond des problèmes. Ce qui entraîne des régressions en cascade, agrave le monolithe, dégrade la qualité et continue à démotiver les équipes.

… ce qui entraîne une perte de confiance des équipes métiers envers la technique, qui rends plus difficile les échanges entre journalistes et technique.

… cercle vicieux infernal, dette technique phénoménale

Il faut un électrochoc, c’est à ce moment que le DSI prends la décision de quitter l’entreprise, et Étienne prends la direction de l’équipe technique.

Il choisit de faire appel à Bastien, expert chez JoliCode pour amener cet électrochoc que l’équipe a besoin.

Le but est donc de monter un projet à la fois ambitieux et attractif pour convaincre la direction et les équipes.

A l’inverse de ce qu’on pensait, la direction a tout de suite adhéré au projet, étant parfaitement au fait de l’immobilisme dans lequel ils étaient et des risques causés.

Une partie de l’équipe n’y adhère pas du tout, et quittent le projet et l’entreprise.

L’impossibilité de gérer à deux salariés tout le quotidien en plus du projet de refonte nous pousse à mettre en jachère le site, les actions et l’équipe technique pour identifier les vrais problèmes et les résoudre à la source

On met en jachère le site actuel, donc on jette tous les tickets : si on fix plus les bugs on ne cause pas de régressions, et ça nous libère pour créer du neuf.

Revenons maintenant sur les aspects techniques du projet. On ne pas aller trop dans les détails, mais plutôt aborder quelques points d’architecture et des problèmes qui nous paraissent intéressant.

On l’a dit, au final rien de bien folichon : du Symfony2, rabbitmq, elasticsearch, varnish, redis, mysql, mongo

le fonctionnel global est ok, modulo les bugs et des problèmes de conception.

La plus grande partie des modifications auront lieu sur le frontend, on place l'intégration au centre du projet, en lui fournissant des contenus dénormalisés facilement utilisable, le but n'étant de ne pas TOUT refaire : déceptif pour tout le monde.

Les enjeux étaient donc :
encapusler l’existant dans une api utilisable.
Inconvénient : en REST c’est trop lent, donc on choisit de tout dénormaliser et de stocker ça dans un stockage secondaire

requêtable => elasticsearch à la rescousse
Et créer une API simpliste avec un bridge Symfony2 / drupal. Attention, nous sommes en drupal 6, il y a un conflit de génération de plus de 5 ans.
pour la performance, nous avons les deux briques déjà citées, du varnish avec un user context cache
et du redis, pour les sessions, le stockage de plein de choses sympas et pas critiques en terme de stockage.

Maintenant que nous vous avons évoqué l’aspect technique, et sachant que la technique et l’humain sont deux facteurs concordants indissociables, nous allons maintenant vous expliquer comment la transition humaine s’est opérée.

Plus de précisions sur la mise en jachère
Contrat entre les métiers et la technique :
Résoudre que des problèmes bloquants et critiques.
Le reste sont considérés comme des améliorations ou sont intégrés en TODO dans le développement de la nouvelle infra.
Les tensions retombent et les esprits s’appaisent
Les deux développeurs internes peuvent donc se consacrer à la mise en place de la nouvelle infra.
Multiplication des prestataires extérieurs (tourne avec 3 à 5 développeurs et 1 intégratrice)

Faire émerger un collectif technique de zero.

Avant de débuter les processus de recrutements, il nous fallait définir quel cadre nous voulions donner à la construction humaine de l’équipe technique de Mediapart.

Instinctivement, on a commencé à parler de collectif technique plutôt que d’équipe technique, pourquoi ?

Collectif éthymologie
Issue de deux verbes latin “lego” et “ligo”

“Lego” signifie “cueillir”, “recueillir”, “rassembler”
“Ligo” signifie “lier ensemble” “nouer”, “resserrer”

Il s’est révélé logique que le choix lexical était juste, nous avions pour envie de fonder un groupe de personnes soudé qui s’abreuve collectivement du savoir de chacun dans un esprit de bienveillance, de sympathie et de partage.

Pour autant
Pas évident de fonder un collectif à deux développeurs en interne :)
Bonne connaissance cependant de ce que nous ne souhaitions pas reproduire. Ce qui donne de bonnes pistes pour donner sens à ce vers quoi l’on souhaite tendre.

Envie profonde de nous éclater techniquement et de nous octroyer du temps à terme pour participer à une veille collective éveillée.

Au travers de valeurs :
- Adhérer au projet, au journal et à la galaxie qui l’entoure
- Pour ça on a beaucoup de chance chez Mediapart d’avoir un journal avec une personnalité forte facilitant une partie de l’adhésion
- Contribuer, partager et participer à l’effort des communautés qui nous tiennent à cœur
- Goût pour l’autonomie et l’indépendance dans le travail,
- Ouverture d’esprit et dialogue, les décisions sont prises de manière collégiales, sauf si aucun point d’entente ne peut être trouvé.

Au travers d'une ambiance :
- Studieuse
- Agréable
- Décontractée

Pour faire avancer notre projet de refonte Web, on embauche… un responsable d’informatique interne, qui résout tous les problèmes des journalistes, nous libère du temps et de la frustration, et redonne confiance aux journalistes envers la capacité de la technique à solutionner les problèmes.

L’arrivée d’un chef de projet nous aide à identifier les besoins courants et à monter un planning sur le projet. Il fait de plus interface avec les journalistes. Satisfaisant tout le monde.

De plus, on encapsule le site existant pour utiliser ce qui fonctionne, on créé une API à base de RabbitMQ, de workers et de contenus dénormalisés dans Elasticsearch afin de pouvoir monter un projet “état de l’art” en Symfony2 sans être dérangé par l’existant. Ca nous évite de devoir tout recoder le scope fonctionnel.

Cependant n’aller pas croire que tout est beau et rose, on a fait plein d’erreurs, notamment de ne pas communiquer quand on a senti que l’on dérapait niveau planning.

Encore une fois, la direction nous a étonné : bien que forcément pas contente que le projet prenne du retard, ils comprennent qu’il y a maintenant une véritable dynamique et que la perte de temps n’est pas un caprice.

Il y a vraiment de la valeur qui est créé.

Pour conclure et rappeler l’introduction, ce n’est pas drupal qui a causé le monolithe ni symfony2 qui a produit une archi de qualité. Votre projet en sf2 peut aussi bien aller droit dans le mur que le début de cette histoire.

Les solutions que l’on a mis en place peuvent vous paraître évidente et simpliste mais ne sous estimez jamais la force l’immobilisme du au quotidien et apprenez à prendre le recul nécessaire pour vous posez les bonnes questions, identifier les points de ruptures et proposer les solutions appropriées à votre situation.

tout dépend de votre personnalité et de la situation peut-être arriverez à provoquer le changement de l’intérieur ou bien peut-être vous devrez quitter l’entreprise pour provoquer cet életrochoc tout en vous assurant une sortie de l’enfer.

Tu ne peux pas construire un projet sans technique
et tu ne peux pas construire de technique sans l’humain.
Travailler sur l’humain, c’est s’assurer des efforts techniques pérennes.