Mise en production le vendredi, mythe ou réalité

Découvrez pourquoi les mises en production du vendredi restent un mythe ou une réalité pour les développeurs web

Tags :

développeur web junior vendredi
Publié le
Temps de lecture : 12 minute(s)
Vendredi, 16h45. Vous venez de passer une semaine à coder une nouvelle fonctionnalité géniale. Vous avez travaillé dur, peaufiné chaque détail, et maintenant, il ne vous reste plus qu'une seule étape pour voir les fruits de votre travail en ligne : appuyer sur "Déployer". La seule vraie manière de vérifier que tout fonctionne, c'est une fois en ligne. Plus de doutes, c'est le moment de voir le résultat en action ! Mais là, une petite voix dans votre tête vous arrête net : "Et si ça foirait tout juste avant le week-end ?" La mise en production le vendredi, c'est un peu comme un coup de poker après quelques verres - ça semble une bonne idée sur le coup, mais vous pourriez le regretter dès que ça tourne mal. Alors, mythe ou réalité ?

C'est quoi une mise en production ?

Dans le monde du développement web, la mise en production (ou déploiement) est l'étape où les modifications, améliorations ou corrections de bugs effectuées sur une application ou un site web sont transférées depuis l'environnement de développement ou de test vers l'environnement "production", c'est-à-dire l'environnement utilisé par les utilisateurs finaux. La mise en ligne actuelle du site.

En bref, c'est le moment ou les changements effectués en coulisse deviennent visible par le grand public.

Quels sont les vrais risques de déployer le vendredi ?

Risques techniques

  • Bugs critiques non détectés : Même avec des tests rigoureux, il existe toujours des bugs importants qui passent inaperçus lors du déploiement.
  • Interruption de service : Un déploiement le vendredi peut entraîner des interruptions de service imprévues qui s'étendent sur le week-end, affectant les utilisateurs et clients pendant une période prolongée
  • Difficulté de rollback : En cas de problème majeur, l'absence d'un système de déploiement automatisé fiable peu rendre le retour à la version précédente complexe et risqué.

Risques organisationnels

  • Manque de support technique : Le week-end, les équipes sont généralement réduites ou indisponibles, ce qui peut retarder la résolution des problèmes urgents.
  • Fatigue de l'équipe : Les développeurs peuvent être moins attentifs en fin de semaine, augmentant le risque d'erreurs lors du déploiement.
  • Stress et pression : La perspective de devoir gérer des problèmes le week-end peut créer un stress supplémentaire chez certains développeurs et affecter l'équipe le lundi matin.

Risques commerciaux

  • Impacts sur l'expérience client : Des problèmes non résolus pendant le week-end peuvent affecter négativement la satisfaction des clients et la réputation de l'entreprise.
  • Perte de revenus : Pour les entreprises e-commerce, de santé ou bancaires, une interruption de service prolongée peut entraîner des pertes financières importantes.
Le risque zéro n'existe pas, même avec les meilleures pratiques en place.

Y a-t-il des avantages à faire une mise en production le vendredi ?

Faire une mise en production le vendredi est généralement déconseillé, mais il peut y avoir quelques avantages dans certaines situations.

  1. Moins de pression et d'attention :
    En général, l'activité est plus calme le vendredi après-midi pour certaines entreprises, avec moins d'utilisateurs et de clients actifs. Cela peut réduire l'impact immédiat si des problèmes surviennent et permet de déployer sans la pression.

  2. Week-end pour surveiller discrètement :
    Si le déploiement se fait sans accroc, l'équipe technique peut profiter du week-end pour observer les effets du déploiement sur le site avec le moins de perturbations. Elle peut ensuite expliquer le lundi s'il y a eu des problèmes, afin d'apporter des améliorations ou de faire des changements éventuels.

  3. Préparer le terrain pour la semaine suivante :
    Tout dépend de la nature de la fonctionnalité, mais déployer une correction mineure le vendredi permet de débuter la semaine suivante sur des bases solides. Ainsi, lorsque vient le temps de réaliser un déploiement plus important le lundi, il est plus facile de gérer les éventuels problèmes en ayant déjà réglé les petits ajustements en amont.

Comment communiquer avec l'équipe lors d'une mise en production ?

Lors d'un déploiement, qu'il soit prévu ou d'urgence, la communication entre les équipes techniques et les autres services est essentielle. Une mauvaise communication peut entraîner des malentendus, des retards ou même des interruptions de service inattendues. Pour éviter cela, il est crucial de définir un plan de communication clair avant, pendant et après chaque mise en production.

Que ce soit pour informer les équipes des tâches à accomplir, répartir les responsabilités ou tenir les utilisateurs au courant de l'avancement, la transparence à chaque étape du déploiement est primordiale. Cela permet non seulement de prévenir des erreurs, mais aussi de réagir rapidement en cas d'incident.

Si vous souhaitez approfondir le sujet, voici quelques outils que vous pouvez explorer pour vos recherches : Slack, Microsoft Teams, Jira, Confluence.

Comment gérer un échec lors d'une mise en production le vendredi ?

Le vendredi, synonyme de fin de semaine et de détente imminente, peut rapidement se transformer en cauchemar pour les équipes techniques si une mise en production tourne mal.

La première étape consiste à avoir un plan de récupération en place, comme la possibilité d'effectuer un rollback rapide. Ce mécanisme permet de revenir à une version plus stable en quelques minutes. Certaines entreprises utilisent des outils de monitoring pour détecter rapidement les anomalies en production, ce qui permet de réagir rapidement avant que l'incident n'affecte trop d'utilisateurs.

Une autre possibilité est d'ajouter une documentation des incidents. Il est crucial de documenter chaque incident de manière détaillée. Une documentation complète ne sert pas seulement à améliorer le processus de déploiement, elle permet également d'apprendre de chaque erreur. En consignant les problèmes rencontrés et les solutions apportées, vous réduisez les risques de répétition des mêmes erreurs lors des prochains déploiements, tout en renforçant la communication au sein de votre équipe.

Automatiser les tests et déploiements

Imaginez que vous faites confiance à votre collègue, vous lui dites : "Hé, n'oublie pas de mettre en ligne mes fonctionnalités !". Premièrement, ne jamais le croire ! L'erreur est humaine, et surtout un vendredi après-midi, quand tout le monde rêve déjà de son week-end !

"L’erreur est humaine, mais en production, elle peut vite devenir légendaire."

C'est un peu comme croire que vous allez arroser vos plantes tous les jours... sans jamais louper une seule fois. La réalité ? Un bug se faufilera dans le tuyau d'arrosage, et la pauvre plante se desséchera lentement jusqu'à finir par mourir dans un coin.

C'est exactement la raison pour laquelle l'automatisation des tests et des déploiements est essentielle. Au lieu de compter sur votre collègue, l'automatisation fait tout ce travail pour vous, de manière systématique et infaillible (ou presque). Pas de stress, pas de bug oublié, et surtout pas de plantes desséchées !

Aujourd'hui, il existe des outils. Mais concrètement, le déploiement se compose en trois étapes principales : création, test et déploiement. C'est la pipeline qui vous permet d'automatiser le processus de déploiement et d'assurer un passage rapide.

Je ne vais pas entrer dans les détails techniques ici, mais si vous souhaitez approfondir le sujet, voici quelques outils que vous pouvez explorer pour vos recherches : Jenkins, Github CI/CD, Travis CI et Circle CI.

Anecdote personnelle :

Je vais être honnête : Malgré tous les avertissements, les légendes urbaines et les histoires d'horreur racontées autour de la machine à café, j'ai déjà déployé du code en production un vendredi après-midi. Oui, un vendredi après-midi ! Vous savez, ce moment sacré de la semaine où tout le monde commence à penser au week-end, et où les dieux du DevOps vous observent, les sourcils froncés.

Pour vous donner un peu plus de contexte (accrochez-vous bien), c'était à une époque où j'envoyais des fichiers via FTP. Oui, en FTP. Pas de backup, pas de Git, juste le bon vieux "je copie, je colle, et on croise les doigts". Imaginez la scène : un vendredi, le soleil se couche doucement, et moi, le doigt tremblant sur la touche "Enter", priant pour que rien ne casse. À ce moment-là, ce n’était plus une mise en production, mais presque un saut dans le vide.

Une fois fait, le doute s'installe immédiatement :

  • "Qu'est-ce que j'ai bien pu oublier ?"
  • "Ai-je bien tout vérifié (console.log) ?"
  • "La base de données ? Oh non... c'est la mauvaise."
  • "Le fichier .env est-il bien caché ?"
  • "C'est du responsive, non ?"
Spoiler alert : ça s’est mieux passé que prévu. Mais disons que ce déploiement aurait très bien pu se transformer en week-end prolongé... au bureau. Il ne manquait plus que j'installe un clic-clac pour dormir.

Tout cela pour dire qu'au-delà des mythes et des réalités, certaines entreprises réussissent encore aujourd'hui à effectuer des déploiements sans aucune difficulté, grâce à des processus entièrement automatisés. Cependant, d'autres continuent à déployer sans automatisation, sans sauvegarde, et parfois même sans utiliser Git.

Ce que j'ai appris de cette expérience, c'est qu'il est essentiel de toujours revoir son travail, de s'assurer que tout fonctionne correctement sur différents environnements, et de ne jamais négliger l'importance de la rigueur à chaque étape du déploiement. Aujourd'hui, avec l'expérience accumulée, je ne prendrais plus le risque de faire de grosses mises en production un vendredi, surtout pour les tâches techniques complexes. Un petit correctif rapide ou une mise à jour facile à corriger, pourquoi pas, mais pour tout ce qui touche à des aspects plus techniques, mieux vaut attendre le lundi. Il est plus sûr d'avoir toute la semaine devant soi pour résoudre d'éventuels problèmes, plutôt que de risquer un week-end perturbé.

Parfois, il suffit d'appuyer sur "déployer" à 15h59 un vendredi, et à 16h02, être déjà dans la voiture, musique à fond, comme si de rien n'était !

« Et maintenant que vous avez survécu à la mise en production le vendredi (sans perdre vos cheveux, j’espère), passons à ce qui pourrait réellement vous causer des cauchemars : les migrations de base de données. »

Conclusion :

Le mythe de la mise en production le vendredi est fondé sur des expériences et des risques bien réels. Les défis techniques, le manque de support le week-end, et le stress que cela peut générer ne sont pas à sous-estimer. Cependant, cela ne signifie pas qu'il est impossible de réussir un déploiement le vendredi. Avec une planification rigoureuse, une automatisation des processus et une bonne communication au sein de l’équipe, une mise en production le vendredi peut se dérouler sans accroc.

En fin de compte, tout dépend du contexte et des pratiques de chaque entreprise. Pour celles qui sont bien préparées et disposent d’un environnement de déploiement fiable, le risque est moindre. À l'inverse, dans les entreprises où la préparation et la communication ne sont pas optimales, ou pour celles dont le cœur de métier n'est pas le développement web, le risque de complications et de stress avant le week-end est bien réel.

Alors, mythe ou réalité ? Tout dépend des bonnes pratiques et de la maturité des processus mis en place.

--

Il est important de souligner que certaines entreprises, notamment celles qui ne sont pas spécialisées dans le développement web, ne mesurent pas toujours les enjeux réels d'un déploiement technique, surtout lorsqu'il s'agit d'un déploiement le vendredi. Ces entreprises, qui n'ont pas forcément une équipe dédiée au développement ou à la gestion de la production, peuvent sous-estimer les impacts potentiels d'une mise en production en fin de semaine.

Les développeurs et l'équipe technique, qui sont en première ligne, ressentent souvent une pression supplémentaire avant le week-end. Non seulement ils doivent gérer d'éventuels problèmes, mais ils peuvent également être confrontés à des retours négatifs de la hiérarchie en cas de bug ou d'interruption de service, ce qui alourdit leur charge mentale. Pour éviter ces situations stressantes, il est crucial que les décideurs et les responsables d'équipes prennent en compte les recommandations des développeurs. Après tout, ce sont eux qui connaissent le mieux les risques et les bonnes pratiques en matière de mise en production.

Il est donc essentiel de créer un dialogue ouvert entre la direction et les équipes techniques, afin de mieux comprendre les impacts d’un déploiement mal planifié et d'ajuster les processus en conséquence. Écouter les conseils des développeurs, surtout lorsqu'ils déconseillent un déploiement le vendredi, peut éviter de nombreux problèmes et garantir un environnement de travail plus serein pour tout le monde.

"Finalement, déployer un vendredi, c'est un peu comme faire sa valise pour les vacances à la dernière minute. Si tout va bien, vous êtes à la plage avec un cocktail... sinon, vous vous retrouvez avec trois chaussettes dépareillées et sans maillot de bain. Moralité ? Mieux vaut bien planifier pour éviter les mauvaises surprises !"

Les réflexions partagées dans cet article ne visent aucune des entreprises pour lesquelles j'ai travaillé. Elles sont basées sur mes expériences accumulées et sur des situations observées et vécues.