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

Pas de release en prod un vendredi !

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

Two socks one making fun of the other one — Deux petites chausettes qui fête le début du printemps et l’arrivée des Birkenstocks —by Midjourney

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.

On a tous vécu au moins une fois une galère avec une mise en prod un vendredi après-midi…

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.

Un mal insidieux

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

La Release roulette

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.

La caricature du type de cerveau nécessaire pour des mises en production manuel — By Midjourney

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.

Le régression maléfique

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 ?

Pas de mise en prod le vendredi qu’ils disaient… — Commits Strip du 23 novembre 2012

Too big to unfail

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.

Rollback hell

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.

Sacralisation

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.

Si mettre en production c’est plus difficile que de trouver le Graal, il faut revoir quelques priorités— By Midjourney

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.

Diagnostique

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

Pas de système de déploiement automatique
Batterie de tests insuffisante
Changements trop importants entre deux mises en production
Système de remise en état (rollback) scabreux
Sacralisation de l’événement

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 !

Traitons le mal

Alors docteur, c’est grave ?

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

Deploy often & with Ease

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.

Do one thing, and do it well

La philosophie UNIX

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.

Tests everywhere

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 !).

Daily Routine

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.

Si pour vous les déploiements sont un chemin semé d’embuche, il est temps de prendre des mesures pour contrer tout cela — By Midjourney

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, …).

Trust your Rollback

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.

Tout va bien, tout est normal, let’s Rollback — By Midjourney

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

Où se trouvent les backups ?
Comment monter la base de données sur le serveur de production ?
Comment remettre la release précédente en production ?
Quelles sont les commandes à lancer pour remonter le serveur ?
Où se trouve le serveur et qui sont les personnes de contacts en cas d’urgence ?

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

Conclusion

Aucun risque — Commits Strip du 29 mars 2019

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.

Il faut briser le cercle vicieux qui ne fait qu’augmenter la fréquence de déploiement, le risque et la perte de confiance.

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 ?

Source

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)
http://chat.openapi.com

Midjourney (2023)
https://midjourney.com

Agence web suisseindépendante

StratégieBrandingDesignDéveloppement

Travaillonsensemble.

Information relative aux bureaux d'Antistatique

Lausanne→

Genève→

Lausanne

Genève