Est-ce qu’on met en prod le vendredi ?

Difficile de trancher cette éternelle question qui taraude les services techniques : est-ce qu’on met en prod un vendredi ? L’équipe « contre » trouve ça impensable. L’équipe « pour » considère que c’est un manque de confiance dans son code. Si tu ne mets pas en prod le vendredi, est-ce que c’est parce que tu bosses à l’arrache ?

Vingt années de carrière, et j’ai toujours du mal à trancher. D’un côté, je veux avoir des week-ends tranquilles, loin des bugs en production, et de l’autre, je devrais faire suffisamment confiance en mon travail pour que ça ne pose pas de souci.

Les précautions

Je bosse beaucoup avec Laravel. Soumettre.fr est sponsor officiel du framework : on se tient au courant des évolutions, on étudie de près les nouveautés et les services de l’écosystème.

On teste notre code (peut-être pas assez, mais on est loin d’être à la ramasse) avec des tests unitaires et fonctionnels (avec phpunit évidemment, mais aussi notamment Laravel Dusk). Quand on me remonte un bug, ma première action est d’écrire un test qui le reproduit, avant de le régler. Comme ça, je m’assure que chaque bug n’arrive qu’une fois, et que je ne casse rien en le réparant.

On bosse avec un administrateur système au top : il dissèque de près nos besoins, préconise des solutions, les met en place, puis nous aide à monter en compétences pour qu’on soit autonomes, sous sa sainte surveillance. On déploie avec Capistrano, qui permet des déploiements sans interruption de service, en intégrant nos tests au process (GitLab-CI). En cas de pépin, la mise en prod échoue, et le site reste en ligne sur la dernière version fonctionnelle. La configuration des serveurs est répliquée via Ansible, donc on sait aussi où on déploie.

Les développements sont validés en preprod par l’équipe Produit avant d’arriver en ligne.

Bref, sur le papier, on est tranquilles – et dans 99.99% des cas, tout roule.

Mais dans 0.01 % des cas…

Je ne peux pas m’empêcher de frémir en repensant aux fantômes du passé. Je ne remonterai pas jusqu’à l’époque où on criait des noms de fichiers dans l’openspace, pour savoir qui bossait sur quoi, avant de les mettre en ligne par FTP (sincèrement, je me demande comment on arrivait à faire du business comme ça). Mais des petits accrocs de mise en prod, j’ai eu le temps d’en voir passer.

Je me rappelle du vendredi où la commerciale est entrée dans l’openspace en m’annonçant que son projet venait d’être signé : un mini-site événementiel, pour la sortie d’un film, avec un jeu en flash type « carte à gratter » pour gagner des places pour l’avant-première. Les maquettes étaient prêtes à être intégrées (réalisées en avant-vente), et l’opération commençait le lundi. Je vous laisse imaginer le niveau de dégueulasserie du code pour que ça rentre dans le timing annoncé. Je vous laisse imaginer aussi qui a oublié de faire tourner le script de génération des instants gagnants en prod. L’opération au tourné plusieurs jours avant qu’on se rende compte que personne ne gagnait. Propre. Le comble ? La commerciale en question, après m’avoir expliqué qu’elle avait vraiment besoin de sa commission parce que son fils avait toujours rêvé de nager avec des dauphins dans la Mer Noire (si si, je te jure), s’est barrée en week-end, à 16 heures.

Je me rappelle du jour où on a poussé en prod la refonte du site d’une radio nationale. Grosse audience. Le service informatique du groupe nous avait filé les identifiants du serveur du prod un peu à la bourre (c’était un gros rebranding, tout le monde était dans le jus). On développait sous Debian, le serveur était sous Solaris. Pour des raisons que je ne m’explique toujours pas, les pontes avaient décidé que la refonte se ferait sous eZ Publish, un CMS connu (et redouté) pour ses nombreuses couches de cache. Problème, en PHP, la fonction glob() (qui lit le contenu d’un dossier) comporte un bug sous Solaris, qui renvoie des dates de fichiers erronées. Boum. Aucun cache, et des animateurs qui balancent l’url du nouveau site toutes les 5 minutes à la radio (pour info, on faisait des pics de 100.000 connexions simultanées). On a souffert.

Je me rappelle du jour où Laravel a changé la façon dont on définit combien de temps une donnée reste en cache avant d’être invalidée (on appelle ça le « TTL » pour « Time To Live », durée de vie). C’était annoncé et documenté. En gros, sans rien changer au code, on est passé de « 10 minutes » à « 10 secondes », forçant le cache à se rafraîchir 60 fois plus souvent que prévu. C’est clairement passé inaperçu quand on a mis à jour le framework, et le serveur de prod s’est pris une grosse claque.

Je pourrais continuer comme ça longtemps.

Je ne mets pas de code en production le vendredi

Ces anecdotes relèvent d’erreurs humaines, on est d’accord. J’adore mon métier, je pense n’être pas mauvais, et j’ai de la bouteille. Ça ne suffit malheureusement pas à empêcher les boulettes d’arriver. Bref, si ce n’est pas indispensable, je ne pousse pas en production le vendredi, ni les veilles de jours fériés.

Évidemment, on fait des exceptions. Si le code répare un petit bug, ça passe. Si on est sur une feature sur laquelle le temps a un gros impact, ça peut le faire. Pour le reste, on attend le lundi, et on fait ça au calme. Très généralement, ça ne change rien, pour personne.

Dans tout projet informatique, il reste une zone d’ombre quelque part. J’estime que ton métier de développeur n’est pas de chercher à tout prix à l’éliminer : le temps t’est compté. Tu ne peux pas toujours prendre le temps que tu aimerais sur chaque feature, la réalité du business finit toujours par te rattraper. Tu dois parfois prendre un risque calculé. Ne pas le reconnaître, c’est te voiler la face.

Par contre, ton taff consiste aussi à être là quand le problème surviendra pour le réparer. Alors on fait comment : tu te caches, en attendant de te faire démonter le lundi matin, ou tu te pourris le week-end ? Et dans ce cas, tu rumines parce que ton boulot t’a encore gavé, ou tu me factures les heures supplémentaires ? Ça pourrait m’inciter à ne pas « laisser passer » l’erreur (souvent humaine, on l’a vu), et ça nous mettrait dans un rapport de force qui est malvenu quand on est tous dans le même bateau.

Comment justifier ça en entreprise ?

Il y a un « détail » que j’ai mis très longtemps à comprendre (comme quoi, je dois quand même être un peu con) : en tant que développeur, lead dev, CTO d’une société, tu n’es pas un simple exécutant. Arrête de te comporter comme tel. Tu n’es pas une victime : pour tes collègues et ta hiérarchie, qu’ils te le montrent ou pas, tu es le sachant sur les questions techniques. Un rôle-clé dans l’équipe, puisque tu as un jeu de compétences indispensables à l’entreprise, et que les autres n’ont pas.

J’ai bossé avec (et pour) de sacrées têtes de mule. Chaque fois que j’ai pris le temps de leur expliquer les tenants et aboutissants d’une décision, celle-ci a été respectée. Mieux : c’est quand j’ai commencé à oser imposer mes décisions que ma carrière a vraiment démarré. Une des clés est d’éviter le jargon : tu ne veux pas étaler ta science, mais faire comprendre les éléments de réflexion qui t’ont poussé à une décision logique. Et la logique, c’est ton boulot.

Évidemment, pour que ça marche, n’attends pas un vendredi 15h pour annoncer qu’il n’y aura pas de mise en production. Il faut savoir anticiper ces choses, prévenir le plus tôt possible, en expliquant pourquoi c’est risqué. Ce n’est pas un aveu de faiblesse !

Si ça n’a jamais été fait dans ta boîte, je te propose de rédiger une politique d’entreprise concernant les dates de mise en production. Détailles-y les contraintes, les interdictions, et les exceptions qui seront admises. Pour aider la pilule à passer, préviens du monde, et envoie-leur en leur précisant que c’est un brouillon et que tu aimerais qu’ils le complètent de leurs avis. Tu verras : ça va négocier vite fait, mais personne ne rechignera. Je ne peux pas te promettre que tu ne mettras plus jamais en prod le vendredi, mais ça sera un excellent début.