KeiruaProd

I help my clients acquire new users and make more money with their web businesses. I have ten years of experience with SaaS projects. If that’s something you need help with, we should get in touch!
< Back to article list

Déploiement, fin de semaine et bon sens

Récemment, la question de savoir s’il faut ou non mettre en prod un projet en fin de semaine a fait apparaître quelques trucs humouristiques, tel que Estcequonmetenprodaujourdhui.info ou bien l’image de CommitStrip.

Mon opinion sur la question est plus proche de celle développée dans l’article d’Yves, même si je trouve sa vision un peu trop manichéenne.

Selon lui les clés d’un déploiement réussi c’est, entre autres :

Toujours selon lui, lorsque l’on maîtrise ces 3 éléments, on peut déployer n’importe quand.

Je le rejoins tout à fait sur le système de déploiement. Sans avoir un process complexe d’intégration continue, il me semble irresponsable de travailler sans un outil de déploiement qui permette d’annuler une mise en prod en cas de problème, et de revenir à un état antérieur stable. Pas besoin d’un système complexe pourvu que ça marche et qu’il soit fiable : je travaille actuellement avec un outil qui doit faire bien moins 30 lignes de script shell, et qui fait très largement ce dont j’ai besoin. Je peux déployer en une commande dans un terminal, et en cas de problèmes, revenir en arrière en une commande. Plein de solutions plus complètes existent, mais cela pourrait être le sujet d’articles dédiés.

Pour le reste, je suis plus modéré : il arrive que du code soit non testé car difficile à tester de manière automatisé, ou qu’il y ait des effets de bords difficiles à reproduire… bref dans la vraie vie, un déploiement, ça ne se passe pas comme ça devrait. N’empêche qu’avec un peu de bon sens et de bons outils, on peut mettre en prod un vendredi, pourvu qu’on maîtrise ce qui est fait.

C’est justement là où je voudrais en venir. Le bon sens.

Voici la scène à laquelle j’ai participé, impuissant :
Il y a 5 développeurs.
Celui qui doit mettre en production est arrivé récemment dans la société et doit réaliser son premier déploiement. Il doit donc être assisté pour utiliser les outils (qu’il ne connait pas), et pour vérifier qu’il n’oublie rien.
Un des autres développeurs doit partir à 17h et faire du télétravail le lendemain. 2 autres donnent une formation à l’étranger (6h de décalage horaire, mais joignables via messagerie instantanée). Le dernier, sur les lieux, n’a que peu d’expérience sur le projet, et n’a pas la main sur de nombreux outils (base de prod, outils serveur, etc…).
La mise en production ayant déjà été retardée à cause de divers problèmes pratiques, le moment où la mise en production peut effectivement avoir est jeudi vers 16h30.
Outils de tests automatisés : aucuns (à mon grand désespoir).
Impact de la mise en production : l’intégralité du site, car liée aux URls (le but étant d’améliorer le SEO).

Fallait-il mettre en production ce jeudi-là ?

Tel que je le présente, il me semble évident que non.

En effet avec n’importe quel outil de gestion de version, comme celui utilisé ici, il est possible pour ce développeur de continuer à travailler sur d’autres choses en attendant de pouvoir mettre en ligne lorsque les conditions sont propices. Je n’aurais pas fait ce déploiement de type ‘big bang’ le lendemain, mais j’aurais attendu le lundi. Le développeur le plus expérimenté travaillant depuis chez lui et 2 des autres n’étant joignables qu’à partir de 15h, celà n’aurait pas été idéal, d’autant plus que l’essentiel de l’activité de la société a lieu au cours du weekend, et qu’il est inconcevable que le site soit KO durant cette période. Bref, dans l’idéal j’aurais attendu lundi. Si ce n’était pas possible (admettons), j’aurais au moins attendu le lendemain, plutôt que de presser un développeur déjà stressé par l’impact potentiellement néfaste de son travail, et par la journée déjà bien avancée.

La mise en production a donc bien eu lieu. La mise en préproduction ayant en effet déjà démarré, les autres développeurs étaient bloqués pour faire les leurs. Divers projets n’attendant que l’arrivée d’un développeur rendaient également pressant ce déploiement. Plutôt que de revenir en arrière et faire le déploiement tranquillement le lendemain, il a été demandé de finir ce qui avait été commencé, afin de laisser la place aux autres par la suite. Intérêt faible : le gain de ce déploiement se consaste après plusieurs semaines, et via la gestion de version, tout le monde aurait pu s’y retrouver convenablement.

Je suis donc convaincu que le choix qui a été réalisé était plus mauvais qui puisse être fait.

Il n’a pas fallu beaucoup de temps pour me donner raison : le déploiement a échoué à cause de nombreux effets de bord qui n’apparaissaient pas dans les autres environnements (ce qui aurait pu  être évité), le déploiement a finalement été repoussé, et une nouvelle branche de travail a du être mise en place pour travailler en parallèle. Quand au malheureux développeur, il est resté jusqu’à 23h pour essayer de déployer, puis revenir en arrière.

Bref, ne pas oublier d’avoir du bon sens. C’est ce que font de nombreuses boites, qui n’ont plus à prouver qu’elles savent avoir une application en ligne. Déployer ne doit pas avoir à ressembler à ceci.