Attention Chérie ça va trancher ! #symfony_live du 10/04/2015

Conférence du 10/04/2015 au #symfony_live 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

Pour faire avancer notre projet de refonte Web, on embauche… un responsable d’informatique interne, qui résoud 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.

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.

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.

Niveau recrutement, il est bien plus facile de recruter un développeur Symfony2 motivé qu’un développeur qui doit toucher à du Symfony2, du drupal, des imprimantes, etc.

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.