Deploy on Friday: brisons le mythe de la malédiction du vendredi

Si t'es dans le Web, tu as forcément déjà entendu cette phrase lancée en plein milieu d'une discussion

C’est comme une règle tacite, un peu comme le fait de ne pas associer chaussettes et sandales.

Le client est rarement celui qui impose cette règle, c’est plutôt une sorte de mantra dans les équipes de devs.
Et honnêtement, personne ne veut se faire appeler pendant le week-end pour corriger un bug à cause d’une mise en prod foireuse.

Mais soyons honnêtes, ne pas déployer un vendredi, c’est traiter les symptômes sans s’attaquer à la maladie.
Les refus de mise en prod certains jours cachent souvent des problèmes plus profonds.

Alors, mettons nos plus beaux gants de chirurgien et examinons - ensemble - chacun de ces symptômes un par un.

Vous êtes paranoïaque à l’idée de déployer un vendredi ? Voici quelques symptômes qui le prouvent.

Le premier symptôme est souvent l’absence d’un système de déploiement automatisé, fiable. 
Ou pire, un système partiellement manuel, pas documenté pour un sou et totalement à la ramasse.

En conséquence, déployer prend un temps fou et nécessite un cerveau surhumain.

Et le pire, c’est qu’en cas de problème, on peu difficilement revenir dans l’état pré-release sans s’arracher les cheveux.

Un grand classique des déploiements catastrophique, un manque de tests de la dernière release.

Que ce soit par nécessité budgétaire ou sous la contrainte du temps, personne n’a eu l’occasion de mettre en place une batterie de tests solide. Du coup, on risque de se retrouver avec des bugs et des régressions, même les plus farfelus.

En cas de pépins, il faut être prêt à tout laisser tomber et corriger tout ça en urgence.
Et le vendredi après-midi, ce n’est pas la meilleure heure pour ça, non ?

Plus on retarde la mise en production, plus on engrenge une montagne de changements. Et plus on en a, plus on a peur de tout faire planter lors de la mise en production.

En clair, c’est comme essayer de tout faire passer dans un Jeans SlimFit taille 34 alors qu’on a pris quelques kilos aux dernières fêtes de fin d’année. Ça risque de craquer de tous les côtés.

Il est tout à fait normal d’avoir des craintes. C’est mathématique, plus les changements sont importants, plus il y a de risques, d’effets de bord.

Quand tout part en cacahuète, la solution la plus simple reste alors un rollback, soit une remise en état du système dans son état pré-release.

Mais soyons honnêtes, on ne sait souvent pas comment ça fonctionne et ça crée un peu de panique. C’est sûr que ce n’est pas très rassurant de déployer sans savoir comment revenir en arrière si jamais ça foire.

Évidemment, devoir déclencher un rollback ce n’est jamais très glorieux, au moins, ça va vous permettre de remettre rapidement votre projet sur les rails et de reporter la mise en production pour des raisons valables.

Malheureusement, la procédure est souvent négligée. Soit le système ne fonctionne pas bien, soit il n’a jamais vraiment été éprouvé ou relancer récemment. Rajoutant ainsi encore plus de stress à notre peur naturelle des déploiements.

Trop souvent les mises en production sont sacralisées. Il en est fait un événement spécial et unique. C’est alors pas vraiment étonnant qu’il y ait tellement de stress et de panique.

Pire, la planification des mises en production sont faites plusieurs semaines à l’avance et doivent être faites en dehors des horaires de bureau — La fameuse release du mardi 20h. 

Donc pour résumé, en général on a un certain nombre de problèmes que l’on peut identifier:

Et comme on a peur de déployer, on le fait rarement, donc on connaît mal le processus de déploiement, ce qui fait que le problème se répand encore plus vite.
C’est la boucle infernale !

Grave, à vous de voir, mais certainement pas catastrophique et heureusement ça se soigne bien !

Tout d’abord, je vous conseille vivement de mettre en place un outil de déploiement continu (Continuous Deployment). Et oui, c’est la base !

Que vous optiez pour un outil maison ou un système éprouvé comme Capistrano, l’important c’est d’avoir confiance en votre outil. Sinon, vous risquez de vivre l’enfer à chaque fois !

Personnellement, nous mettons systématiquement en place Capistrano dans nos Github Actions pour l’ensemble de nos projets.
Ainsi nous déployons nos projets Symfony avec Capifony et Drupal avec CapDrupal.
Nous avons également réalisé nos propres recettes pour les projets WordPress et NextJS.

Il n’y a pas d’outil parfait, à vous de trouver le vôtre et de construire votre écosystème autour.

Si vous voulez éviter de vous retrouver avec une montagne de changements gargantuesques, il faut déployer souvent (merci le déploiement continu) et tenir à jour un CHANGELOG.md de vos modifications.

Nous chez Antistatique, on à adopter le format Keep a Changelog , qui nous permet d’annoncer toutes les modifs à nos clients — à chaque Release — et de garder un œil sur le contenu exact de nos mises en production, sans se prendre la tête à fouiller dans l’historique Git.

Il va falloir mettre les mains dans le cambouis ! Mais rassurez-vous, ce n’est pas insurmontable.
Pour éviter les régressions, il vous faut des tests unitaires et des tests fonctionnels.

Les tests unitaires vont vous permettre de vous assurer que le code que vous avez écrit est bien conforme à vos attentes, sans régression ni erreur.

Quant aux tests fonctionnels, il existe plusieurs solutions selon ce que vous voulez tester. Mais en gros, ils vous permettent de vous assurer que votre application fonctionne comme prévu pour l’utilisateur.

Personnellement, j’aime bien les outils Behat ou Cypress pour les tests purement fonctionnels.
Pour les tests unitaires, on utilise principalement PHPUnit et Panther (oui, même pour WordPress !).

Faire une mise en production ne devrait pas être un événement d’importance apocalyptique. C’est important de les planifier, mais il ne faut pas non plus que ça vire au psychodrame.

Plus on en fait, moins c’est stressant. Et puis si vous releasé plus souvent, vous aurez moins de choses à tester à chaque fois, donc moins de risques de tout casser. CQFD.

Chez nous, nous déployons tous les jours. Nous n’avons pas vraiment de règle ou de condition pour ne pas déployer. À l’exception d’événements spéciaux chez nos clients. Comme par exemple une conférence de presse de l’un de nos clients ou une démo, où le moindre down-time (site inaccessible, ce qui est en général de quelques minutes lors d’une mise en production et qui peut s’étendre à plusieurs minutes en cas de rollback) serait inacceptable.

Il nous arrive également de refuser des mises en production, lorsque l’équipe en charge du projet n’est tout simplement pas présente (vacances, maladies, …).

Les déploiements qui fails, on sait tous que ça peut arriver, même aux meilleurs. Donc voici mon meilleur conseil: automatisez tout ce qui peut l’être et documentez le reste.
Soyez réalistes, tout ne peut pas être automatisé. 
De ce fait, vous devez documenter les étapes de manière claire et précise.

Je vous assure, quand le système est down et que vous êtes en mode panique, vous serez content d’avoir une procédure “step-by-step” sous la main.
Ça vous évitera de faire des bêtises et de devoir réfléchir alors que vous êtes déjà en mode survie.

Donc, prenez le temps de documenter tout ce qui peut être documenté:

Et surtout, n’oubliez pas de tester votre procédure de rollback régulièrement pour être sûr que tout est bien à jour.

Il faut savoir préparer le terrain en amont. Avoir une bonne stratégie de déploiement et des outils efficaces vous permettront de déployer avec confiance et tranquillité d’esprit, même un vendredi à 17h. Il faut également avoir une procédure de remise en état efficace et fonctionnel. 

Une fois ces outils en main et ceux-ci maîtriser alors vos mises en production se feront Finger in the Nose. Au pire des cas, un rollback et on prend le temps de comprendre ce qui vient de se passer.

Et si vos clients sont toujours réticents, dites-leur simplement : “On peut le faire, mais on va prévoir des pizzas et de la bière au cas où !” 😜🍕

Et vous, vous dites quoi à vos clients lorsqu’ils demandent de déployer en production un vendredi ?

Yves Brissaud (Mar 2013) Ne pas pousser en prod le vendredi. FAUX !
http://log.winsos.net/2013/03/12/ne-pas-pousser-en-prod-le-vendredi-faux.html

Ruby K V (Déc 2021) Fear Of Production Deployment — A Never-Ending Tale?
https://www.linkedin.com/pulse/fear-production-deployment-never-ending-tale-ruby-k-v/

Alessandro Minoccheri (Jan 2021) Why you should deploy on Friday without fear
https://medium.com/flowingis/why-you-should-deploy-on-friday-without-fear-80a26d3c17c1

Kyrylo Yefimenko (Déc 2020) The Fear of Deployment Factor
https://engineering.talkdesk.com/the-fear-of-deployment-factor-48cf09095f16

Mark Levy (Avr 2022) How to Deploy Code Without Fear
https://www.opsmx.com/blog/how-to-deploy-code-without-fear/

Steve Ardalis (Mar 2022) Deploy More Often
https://ardalis.com/deploy-more-often/

Candost Dagdeviren (Déc 2021) Why should you deploy your code in smaller chunks and release software often?
https://candost.blog/why-should-you-deploy-your-code-in-smaller-chunks-and-release-software-often/

Matt Rickard (Oct 2022) Deploy Early, Deploy Often 
https://matt-rickard.com/deploy-early-deploy-often

Cédric Hulin (Mar 2022) Ne déploie pas en production un vendredi !?
https://www.linkedin.com/pulse/ne-d%C3%A9ploie-pas-en-production-un-vendredi-c%C3%A9dric-hulin

Aurone (Juin 2022) La mise en production du vendredi à 17h
https://www.aurone.com/blog/la-mise-en-production-du-vendredi-17h/

@PasLeVendredi (2023) Votre rappel hebdomadaire que les mises en prod le vendredi, c’est interdit.
https://mobile.twitter.com/paslevendredi

Est-ce qu’on met en prod aujourd’hui? (2023)
https://www.estcequonmetenprodaujourdhui.info

ChatGPT (2023)
https://chat.openapi.com

Midjourney (2023)
https://midjourney.com