De l’artisanat aux bases de l’industrialisation

Cet article ne parle pas de code. Il parle de mes premiers mois chez Chouettagence, où j’ai fait ce que j’ai pu pour « industrialiser » les processus qui étaient encore très artisanaux malgré une équipe comptant pas loin de 20 développeurs.

Tout commence bien

Cette année, pour moi, était vraiment celle du changement. J’ai décidé de quitter Èssèsdeuzi, une SSII de 600 personnes dans laquelle je travaillais depuis deux ans, pour une entreprise plus petite. Je ne voulais plus créer un ticket pour demander le moindre service au système ou à l’équipe d’hébergement. Je ne voulais plus de projets au forfait pour des grands comptes, qui durent des mois et des mois au détriment de la qualité du code, du site et de mes nerfs. Donc, pour la première fois de ma courte carrière, j’ai posé ma démission, et j’ai mis les voiles.

En juin, me voilà donc arrivée dans Chouettagence, une agence web de 40 personnes, soit quinze fois moins que chez Èssèsdeuzi.

Tout commença très bien : Chouettagence prenait bien mieux  soin de ses employés que Èssèsdeuzi, et favorisait beaucoup la veille technologique par les développeurs. J’étais très heureuse d’avoir changé de boîte, le ciel me semblait bleu. Je n’ai pas tardé, hélas, à remarquer de sombres nuages à l’horizon.

L’envers du décor

Je me rappelle exactement comment j’ai réalisé que quelque chose n’allait pas. À l’entretien d’embauche, DirecteurTechnique m’avait expliqué que les équipes travaillaient avec git. Le jour de mon arrivée, j’ai donc demandé à mon collègue, celui qui était assis à côté de moi, où étaient les dépôts git, histoire que je puisse cloner, configurer et bosser.

Il a pincé les lèvres et m’a regardé tristement, comme s’il n’avait pas vraiment envie de répondre. Et, d’ailleurs, il a esquivé la question !

Il y avait de quoi. Tous les développeurs travaillaient sur la même instance du code, partagée via un montage NFS. De temps en temps, quand ils y pensaient, ils commitaient leurs fichiers sur le dépôt git local. Stupeur. Premiers tremblements.

Les mises en prod, quant à elles, consistaient à envoyer manuellement les fichiers sur les serveurs de prod depuis FileZilla. Tout cela, évidemment, depuis l’instance de dev sur laquelle travaillaient plusieurs développeurs en même temps. Stupéfaction. Sueurs froides.

Voici un petit florilège de phrases que l’on entendait alors régulièrement dans l’open space.

  • « Hey Georges, est-ce que tu as fini de travailler sur bidule.inc ? Il faut que je fasse mes modifs aussi… »
  • « C’est bon ? Je peux envoyer le fichier toto.htm en ligne ? »
  • « Je vais passer trucmuche.class.inc en prod pour que le client puisse tester. »
  • « Haaaann t’as envoyé la dernière version de machin.js en ligne ? MON DIEU NON ! »
  • « Oh, le site est cassé. Ah bah oui, j’ai oublié d’envoyer chose.class.inc en ligne… »
  • « Oh, le site est cassé. Pourquoi ? [Recherche de deux heures…] Ah oui, la structure de la base n’est pas la même en dev et en ligne… »

Je ne sais pas ce que cela vous évoque. Personnellement, entendre cela m’inspire le plus profond désespoir.

Ce genre de phrases, à mon sens, ce n’est pas du tout ce que l’on est censé entendre dans un open space empli de développeurs professionnels. Il existe des outils et des méthodes pour éviter d’entendre cela.

Deux solutions : la fuite… ou le retroussage de manches

Ma première envie a été simple : fuir, trouver un autre boulot. J’avais deux offres de CDI qui attendaient encore dans ma boîte mail. C’était facile.

Avant de fuir, j’ai toutefois parlé à DirecteurTechnique, celui-là même qui m’avait embauchée. Il m’a dit quelque chose de très simple :
« Si tu veux lancer des projets d’industrialisation, vas‑y. C’est ça que j’attends de toi. »
C’était fou. Alors qu’on m’avait toujours dit « nous allons voir ce qu’on peut faire » chez Èssèsdeuzi, voilà qu’on me disait « fais ! ».
Sur le coup, je me suis sentie… Comment dire ? Trop libre.
J’ai pris une grande inspiration. J’ai inscrit sur un papier ce qui n’allait pas et surtout ce que je voulais à la place. Quand on veut changer les choses, il ne faut pas se contenter de dire ce qui ne va pas : il faut proposer des solutions.

Voici ce que j’ai noté sur mon papier :

Problème Pourquoi ça pose problème Solution
Les développeurs travaillent tous sur la même instance de développement.
  • Ils ne peuvent pas travailler à plusieurs sur les mêmes fichiers. => Ils perdent du temps à attendre que leurs collègues aient fini.
  • Ils ne peuvent pas être sûrs de ce qu’ils envoient en production. => Ils perdent du temps à chercher la réponse, ou ils envoient des développements inachevés en prod. L’entreprise perd en crédibilité auprès des clients qui ont payé pour le site.
  • C’est moche. :”( (Oui, bon, d’accord, mais ça ne suffit pas comme argument.)
  • Séparer les instances de développement : mettre en place une instance du code — et du site — par développeur.
  • Utiliser git pour partager les sources, pas seulement pour gérer l’historique des versions.
Les mises en production sont manuelles via FileZilla.
  • Risque d’erreur humaine très élevé, d’où de gros risques d’instabilité en production.
  • Automatiser les mises en production pour avoir une solution de type « j’appuie sur un bouton et la dernière version stable est envoyée en prod ».
Les évolutions sur le schéma de base de données sont effectuées manuellement par les développeurs, en dev, puis en prod.
  • Risque d’erreur humaine élevé (on se répète…).
  • Introduire un système de migrations automatiques des bases de données, de sorte que celles-ci soient versionnables au même titre que le code.
Pour faire tester quelque chose à un client, le seul moyen est d’envoyer quelque chose en prod.
  • Risque de bugs en prod.
  • Échanges plus longs, de type « ah mais non c’est pas du tout ça qu’on voulait, mon bon monsieur ».
Mise en place (au moins) d’une plate-forme de préproduction, intermédiaire entre le développement et la production.

Écrire ce tableau, formaliser les problèmes, m’a beaucoup aidée par la suite : il n’avait que quatre lignes. Ainsi, il n’y avait donc « que » quatre choses à faire pour arranger les choses. La deuxième colonne contenait des arguments de choix pour convaincre de la nécessité du changement : « risque d’erreur » et « perte de temps » sont des choses que j’ai beaucoup répétées.

Lancer le changement…

J’avais identifié le problème no 1, celui qui me dérangeait le plus : cette histoire d’instance de développement unique par développeur.

irecteurTechnique, qui, grâce à ses dix ans de boîte, maîtrisait beaucoup mieux que moi l’architecture du SI de Chouettagence, a mis en place les bases techniques de la solution à ce problème.

Mais l’existence de la solution technique ne suffisait pas : il fallait pousser les développeurs à l’utiliser ! C’est là que je suis intervenue. Pour communiquer.

Tout d’abord, il a fallu expliquer le principe d’un gestionnaire de versions, les commandes git de base, etc. Pour cela, les séminaires techniques (réunions hebdomadaires d’une heure, durant lesquelles les développeurs discutent de leurs trouvailles de la semaine) se sont révélés très précieux. J’ai présenté git et git flow lors d’un séminaire technique, et l’architecture proposée par DirecteurTechnique à un autre séminaire. J’ai bien insisté sur pourquoi nous voulions cette solution. Retenez ceci : expliquez pourquoi vous voulez changer. Si vos utilisateurs ne sont pas convaincus de l’utilité du changement, ils le suivront à reculons, et ça ne fonctionnera jamais !

Heureusement, mes collègues étaient, pour la plupart, déjà demandeurs de changement de ce côté-là. Les arguments de mon tableau ont rapidement convaincu les derniers.

Entre les séminaires, pour les aider à se former à git, je postais régulièrement mes trouvailles (et des arguments supplémentaires) sur le RSE (réseau social d’entreprise). Imaginez un facebook interne à l’entreprise, utilisé pour partager blagues et liens de veille techno. Le RSE s’est révélé être un excellent moyen de toucher l’ensemble des développeurs et de leur permettre de retrouver rapidement les liens utiles que je partageais.

… un pas à la fois, et en acceptant des compromis

Il a fallu accepter des compromis. L’architecture que je visais, par exemple, c’était quelque chose de très carré, avec une base par développeur, des mises en production automatisées à partir d’un dépôt git bare…

Oui, mais il y avait beaucoup de mais. À force de discussions, nous sommes arrivés à une architecture moins jolie, avec une instance de code par développeur, mais une seule base de données pour les instances de développement. Les mises en production sont toujours manuelles, mais elles se font à partir d’une instance du code que les développeurs ne modifient pas directement, une sorte de clone sacré sur lequel on n’a le droit de faire que des git pull.

Ce n’est pas parfait. Si une grosse modification de la base de données est effectuée par le développeur A, le code des développeurs B et C peut devenir instable. En pratique, sur les projets courants, ce défaut n’est pas trop dérangeant : généralement, les modifications de base sont rétrocompatibles avec l’ancien code.

De plus, le processus de développement est devenu bien plus complexe : avant, les développeurs codaient, puis envoyaient leurs fichiers en ligne et basta. Maintenant, ils git pull, ils codent, ils git commit, ils git fetch, puis ils git merge, puis ils git push, puis ils font un git pull sur le dépôt sacré, et enfin, ils peuvent envoyer leurs fichiers en ligne. Ça en fait du boulot, pour prétendument gagner du temps ! Et je ne vous parle même pas de la psychorigide un peu bizarre qui leur tape dessus pour qu’ils testent soigneusement leur code avant le git push. Pauvres, pauvres développeurs.

Surtout, puisque les mises en prod sont toujours manuelles, on risque toujours de se tromper.

Certes. Mais un petit git diff –name-status [commit1] [commitn] permet de lister les fichiers modifiés pour ne pas en oublier.

En réalité, même si ce système est imparfait, il est déjà bien meilleur que l’ancien. Même si les développeurs tapent plus de choses dans leur ligne de commande, il nous a permis de gagner du temps et d’économiser beaucoup d’énergie.

Ainsi, un changement somme toute assez simple à mettre en place a déjà supprimé pas loin de 80 % des phrases hérisse-poil que j’entendais au début de mon CDI. Ça s’appelle la loi de Pareto.

Ne pas faire trop de compromis

Autant j’ai accepté certains compromis, autant j’ai été intraitable sur d’autres points. À partir du moment où l’on a commencé à utiliser git « pour de vrai », j’ai mené une chasse sans pitié aux commits foireux et aux messages de commits non significatifs. J’ai menacé des pires souffrances ceux qui avaient modifié des choses et les avaient envoyées en prod sans les commiter sur git.

C’est très bien d’être sans pitié de la sorte, à une condition : précisez à l’avance ce que vous attendez de vos collaborateurs. Si vous leur tombez dessus à bras raccourcis pour avoir fait une chose dont ils ne savaient pas qu’elle était interdite, vous risquez d’être franchement contre-productif.

Conclusion

Pour l’instant, nous n’avons « que » mis en place l’utilisation de git. Il reste encore beaucoup à faire pour pouvoir parler d’industrialisation aux petits oignons, et pourtant nous avons déjà gagné beaucoup de temps !

Deux conclusions s’imposent : d’une part, si vous codez (ou créez) sans gestionnaire de versions, même si vous êtes tout seul, mettez-vous‑y dès maintenant ! Cela vous permettra d’expérimenter, d’avoir droit à l’erreur, et vous serez prêt quand il faudra que quelqu’un d’autre participe à votre projet (ce qui pourrait bien arriver plus tôt que prévu).

D’autre part, si vous voulez changer les choses au travail, préparez-vous à y investir beaucoup d’énergie. Prenez le temps d’expliquer les raisons du changement pour obtenir l’adhésion des personnes concernées. Prenez aussi le temps de former tout le monde aux nouvelles technologies que vous introduisez. Et aussi, soyez pragmatique, pas dogmatique : acceptez les compromis.

Voilà, c’est tout. Gitez bien. ;)

5 commentaires sur cet article

  1. Nicolas Chevallier, le mercredi 26 décembre 2012 à 10:35

    Je n’ai pas connu de cas aussi désespéré, mais c’est vrai que les équipes de développement ont tendance à créer des raccourcis si les procédures sont trop longues/fastidieuses…

  2. Agnès, le mercredi 26 décembre 2012 à 11:42

    C’est pour ça que je continue la lutte pour simplifier, tout en restant « rigoureux ». La situation est clairement encore loin d’être idéale. La prochaine étape, qui est en cours de test sur quelques projets, c’est d’automatiser les mises en prod à partir du dépôt partagé pour éviter toute la partie push-pull-filezilla. On hésite sur les outils à utiliser pour ça, entre le rsync maison et des outils comme capistrano ou phing. Donc on expérimente pour voir la viabilité des solutions.

  3. Nicolas Chevallier, le mercredi 26 décembre 2012 à 18:33

    De mon côté pour les projets PHP j’utilise Ant pour récupérer les sources sur SVN, compresser/concaténer les CSS et JS, créer les sprites CSS et déployer.

  4. Laure, le lundi 31 décembre 2012 à 12:37

    Merci pour cet article, je suis un peu novice en matière de git, tout ça… Auriez-vous des tutoriels pour apprendre à utiliser ce service facilement ?

  5. Agnès, le jeudi 3 janvier 2013 à 16:04

    Bonjour Laure,
    Le tutoriel du site du zéro est très progressif et part de… eh bien, de zéro. C’est avec celui-là que j’ai commencé. http://www.siteduzero.com/tutoriel‑3–254198-gerez-vos-codes-source-avec-git.html

    Sinon j’aime bien « git magic » pour aller plus loiin : http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/fr/
    et « pro git » : http://git-scm.com/book/fr