Ne déploie pas en production un vendredi !

Et pourquoi pas, après tout ?

Adrien Guéret
Technologie @ OpenClassrooms
4 min readMay 27, 2019

--

Après plusieurs jours de travail, le ticket sur lequel je bosse est enfin prêt à être déployé en production. Développer la nouvelle fonctionnalité n’a pas été difficile et la code review s’est passée plutôt rapidement.

Les premiers déboires ont commencé lors de la review UI : des marges un peu aléatoires, des éléments pas tout à fait centrés, des tailles de polices un peu inexactes… C’est toujours une histoire de quelques pixels, mais notre équipe de designers a l’œil.

Ces soucis corrigés, le ticket est passé dans les mains de l’équipe QA.
Ils sont redoutables, les QA. Ils ne laissent rien passer, les QA.
Bien entendu, ils ont trouvé des choses à redire : une sombre histoire de données non synchronisées lorsque l’utilisateur tape trop vite au clavier. Pour trouver ce type de bugs farfelus, nos testeurs ne doivent pas être de vrais humains mais plutôt un genre de supers robots…

Bref, je suis parvenu à corriger leurs retours ; mon ticket est maintenant à un clic d’être déployé en production… mais quelque chose ne va pas.

Aujourd’hui, c’est vendredi.

Une vieille croyance persiste chez les développeurs : déployer un vendredi, ça porterait malheur. Le ticket le plus insignifiant pourrait faire planter la production si on le déploie un vendredi.
On ne compte plus les histoires de sites inaccessibles, de développeurs honteux et de week-ends gâchés à cause d’une tâche mise en production un vendredi. Une règle d’or est alors venue naturellement :

Ne déploie pas en production un vendredi !

Je me retrouve donc avec mon ticket terminé, validé par toute l’équipe, mais une vieille légende m’empêche de concrétiser tout ce travail.
En plus, aujourd’hui signe la fin du sprint ; cette tâche est la dernière de mon board, si je la passe j’aurai complètement terminé mon sprint !

C’est vraiment trop bête de s’interdire de déployer alors qu’on est sûr que tout fonctionne parfaitement…

Je me rappelle alors que certains développeurs sont un peu moins stricts sur cette règle : ceux-là tolèrent le fait de déployer un vendredi matin. En cas de problème, on a en effet toute la journée pour y remédier.
Galvanisé par cette réflexion, je m’apprête à cliquer sur le bouton… mais quelque chose ne va pas.

Il est 16h34.
Pas vraiment le matin…

Alors quoi, je laisse tomber ? Je me dis que je ne passerai le ticket que lundi prochain ?
N’est-ce pas un aveu de faiblesse ?

Lorsqu’on refuse de déployer un vendredi, c’est parce qu’on a peur qu’un accident arrive. On craint qu’un bug imprévu ne survienne.
En bref, c’est parce qu’on n’est pas confiant à 100 % du comportement de notre application.

Pourtant, aujourd’hui, la plupart des entreprises ont un système d’intégration continue pour s’assurer un produit toujours plus fiable et solide. OpenClassrooms n’échappe pas à la règle :

  • des tests unitaires sont automatiquement lancés ;
  • nos collègues effectuent des revues à chaque étape de vie d’une tâche, que ça soit des revues de code ou de design ;
  • nous avons des environnements de staging répliquant notre environnement de production ;
  • des tests fonctionnels nous assurent que rien n’est cassé ;
  • même si une mauvaise surprise arrive après la mise en production, il nous suffit de cliquer sur un simple bouton pour revenir en arrière.

A quoi bon avoir tout ça si, au final, on s’interdit de déployer un vendredi ?

Refuser de mettre en production un vendredi, c’est simplement ne pas avoir confiance en son environnement de travail.
Votre équipe s’interdit de mettre en production en fin de semaine ? Cela est sujet à débat de manière systématique ? Ne cherchez pas, vous avez un problème dans votre workflow. Avoir confiance dans sa méthode de travail, c’est la clé.

En ce qui me concerne, j’ai confiance. Alors en ce vendredi 10 mai 2019, je clique sur ce bouton, même s’il est maintenant 16h35.

Je suis tellement confiant que je me permets d’écrire en parallèle un article sur ce déploiement... !

Bon… Je dois avouer que j’ai légèrement romancé cette mise en production. La réalité est que je n’ai pas hésité une seule seconde à déployer ce ticket.

D’ailleurs, aucun de mes collègues n’a ce genre d’hésitation : à OpenClassrooms, nous avons confiance en nos outils. Nous mettons en production plusieurs fois par jour, quel que soit le moment de la journée. Et même le vendredi !

Le vendredi maudit n’est donc pas une réalité chez nous, et il ne devrait l’être nulle part.

À OpenClassrooms, le vendredi est un jour comme un autre.

Et vous ? Êtes-vous parvenus à vous débarrasser de cette crainte du vendredi ?

--

--

Adrien Guéret
Technologie @ OpenClassrooms

Front-End developer, working at OpenClassrooms. Also Nintendo enthusiast :)