Opinion (impopulaire) : Les releases du vendredi

Hier vers 17h (un vendredi), j’ai appuyé sur le bouton du lancement de mise en production d’un logiciel sur lequel je travaille.

QUOI !? UNE MISE EN PRODUCTION UN VENDREDI ?! MAIS TU ES FOU.

Beaucoup de gens, sites Internet, ou des discussions prêt de la machine à café, par exemple.

https://www.estcequonmetenprodaujourdhui.info/

Murphy surveille les productions

Alors oui, si une mise en production se passe mal un vendredi, ça va surement amener à travailler d’urgence un samedi ou alerter le support d’astreinte. Ce qui est généralement pas super agréable pour n’importe quelle personne.

Par exemple, il y a quelques années, une mise en production un vendredi contenait un de mes patchs qui brisait le client windows (aaaah les dlls). Beaucoup de tickets sont arrivés durant le week end. Et je me suis senti un peu mal le lundi matin en comprenant l’erreur, ou plutôt MON erreur.

Mettre en production le vendredi est sans doute le pire moment de la semaine dans certains cas car:

  • Le week end est potentiellement un moment ou le plus d’utilisateurs vont avoir le temps d’utiliser l’application
  • Comme mentionné auparavant, personne ne veut debugguer des problèmes le week end.
  • Tu ne vois généralement le résultat que plusieurs jours plus tard
  • etc.

La recherche de sensations fortes

Cependant, livrer au pire moment possible et se retrouver à devoir gérer ce qui s’en suit oblige à remettre en question ses processus pour ne jamais avoir à tomber dans ce cas.

À l’époque de mon patch qui avait tout cassé, je ne choisissais pas la date de mise en production. Par contre je choisissais ce que je soumettais comme patchs. J’ai aussi dû fixer quelques mises en production à des moments chiants, mais au fond, se mettre en face de ses erreurs oblige à monter en qualité, s’assurer de ne rien casser, que ce soit par le biais de tests automatisés ou manuels, prendre en main les pipelines de mises en production, etc.

Nul besoin d’être comme chez Google, GitHub ou Netflix (ou les services cassent aléatoirement pour simuler un tas de problèmes) et de mettre en production X fois par jours avec de l’automatisation à tous les niveaux pour ne pas avoir peur de livrer un vendredi. Mais si tu arrives à avoir un processus ou tu es certain de la qualité de la livraison, le vendredi à 17h est un horaire sans importance outre l’heure de profiter de sa terrasse.


Alors non, je ne recommande pas de mettre en production les vendredis pour une raison particulière. Pour moi, la seule règle est de ne pas livrer quelque chose qui n’est pas prêt à être livré ou si il est possible d’avoir à fixer la production pendant plusieurs heures juste après.

Bref, mettez en production quand vous jugez avoir quelque chose à mettre en production.

10 commentaires

Attention à ne pas mélanger release ("sortie" de la version) et deployment (mise en prod).

Dans beaucoup de cas (Netflix, Google, etc.) les deux se font dans la foulée, et le code est immédiatement déployé et c’est une excellente chose. Mais ce n’est pas applicable tout le temps (c’est impossible dans ma boîte actuelle, typiquement, car l’installation se fait sur un système isolé du réseau).

Tu peux faire une nouvelle release le vendredi à 17h55 sans risque, alors qu’ici tu parles bien de déployer la release chez un client le vendredi soir.

Nul besoin d’être comme chez Google, GitHub ou Netflix (ou les services cassent aléatoirement pour simuler un tas de problèmes) et de mettre en production X fois par jours avec de l’automatisation à tous les niveaux pour ne pas avoir peur de livrer un vendredi.

Aboutir à un processus optimisé qui garantit la qualité des releases est indispensable, je suis bien d’accord, mais selon moi, avoir confiance en ses releases passe obligatoirement par l’automatisation du maximum possible d’étapes du processus de fabrication du logiciel. Typiquement, moins les humains interviennent manuellement dans la production de la release, moins ils risquent de faire une connerie. :)

+3 -0

Je suis plutôt d’accord, quand on maîtrise ce qu’on fait et qu’on prête attention à la qualité, le jour et horaire de prod importe peu. Mais bon, s’il n’y a pas d’urgence particulière et que le clic peut attendre le lundi, ça ne sert à rien de prendre un risque, si petit soit-il. ^^

En fait, cette question ("dois-je mettre en prod maintenant ?") devrait se traiter surtout de manière rationnelle. Gestion de risque, d’impact, d’urgence, de responsabilité, etc. Tout ça c’est assez mathématique finalement. Quand on a trouvé la formule qui marche à peu près, on ne se pose même plus la question en fait.

+0 -0

Justement prendre du risque permet de forcer à l’éviter à terme. D’où ce billet. Comme le fait de jouer avec le feu quand tu es petit t’apprends à ne pas toucher les flammes.

Par contre en effet je ne parle que de deploy. Pour ma part c’est lié avec le pipeline de release.

Huumm :)

Cela dépend de l’objet de ton change et impacts sur la production / utilisateurs finaux.

Un CHANGE de mise à jour critiques tu le déploierai selon moi entre le Lundi et le Jeudi. Un change MAJEUR infra avec un plan de retour arrière et / ou des steps log du au backup ou réplication + tests… tu le fais un vendredi, avec les ressources déjà bookés

Dépend grosso modo de ce que tu prends sur le run ou en mode hors reccurent aussi. Mais selon moi la prioritée reste sur les impacts.

Ex :

_ Infra messagerie / EDI / Flux d’échange B2B…

sera différent

_ de serveurs de fichiers bureautique

Une mise à jour de sécurité via CHANGE URGENT, tu te poses pas la question, tu déploies avec un minimun d’étude en amont !

Cela se discute en général en CAB, avec une procédure spéciale pour les changes "urgents".

Désolé mais j’ai absolument rien pigé au message ci-dessus.

Je tenais à le signaler parce que je pense pas être le seul.

nohar

Hello, j’entends ici le point. Je prendrai le temps ce soir de reformuler.

Je suis peut-être parti du postlat où l’ensemble du public était familiarisé avec ITIL / CMMI et autres démarche de processus qualité.

Je rejoins Spacefox. J’etais plutôt de l’avis de « peu importe le jour de la release sur un projet maîtrisé et tout testé de façon automatisée ». Judqu’au jour où j’ai commencé à prendre des astreintes. Se faire réveiller un samedi dans la nuit parce qu’un memory leak d’une application déployée le vendredi midi chatouille une plateforme mutualisée, ça fait vraiment pas plaisir. Tout était ok dans cette release, les stress tests automatisés passaient pourtant bien sur la plateforme dédiée. Mais pas sur l’environnement de production.

Et vraiment, à 3h du matin de la nuit de samedi à dimanche on se demande vraiment 200 fois ce qui justifiait une mep un vendredi.

Donc oui, les différents commentaires sont justes : tout doit être automatisé pour donner un maximum de sérénité et permettre de déployer n’importe quand. Mais ça va arriver qu’une release plante la prod. C’est inéluctable. Autant éviter que ce soit dans un moment pénible pour les gens d’astreinte 😎

+1 -0

J’essaye d’éclaircir mon propos, non compris plus haut.

ITIL :

Démarche de bonnes pratiques sur la gestion d’un système d’information. Cette démarche et majoritairement utilisée sur les socles techniques au même titre que CMMI est utilisée pour les développements de projets informatiques.

il y a 6 processus majeures, dont :

  • Gestion du centre de service
  • Gestion des changements
  • Gestion des incidents
  • Gestion des problèmes
  • Gestion des mises en production
  • Gestion des configurations

Ici, la gestion des changements, mise en production et configuration sont très proches.

Production industrielle (via ITIL):

En synthèse, toute modification d’un asset communément appelé C.I. (Configuration Item / carte réseau, fichier paramètre, disque dur, site…) doit faire l’objet d’un CHANGE (gestion des changements) dans les outils "IT Service Management" (ITSM / ServiceNow, HP Care, JIRA, MAXIMO…).

Il y a plusieures catégories : mineur, standard, majeur, urgent…

Un changement peut-être planifié, issue d’un incident, dans divers envirronement.

Le Service Delivery Manager, ici peut organiser le service fonction des cas :

Mise en prod : ressources dédiées et planifiées en amont (pouvant intervenir hors astreinte un W.E) Change Urgent: planifié ou non (cas issue d’un IN), avec support de l’astreinte en Week End si soucis… _ Change sécurité : immédiat effectuée par le support disponible (astreinte si WE…)

Il va de soit que le Business, donnera la priorité aux arbitrages.

Voili voilou, en espérant avoir été plus clair, sans être indigeste.

Bon Week End et fêtes de paques. :ange:

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte