Je prône les mises en production fréquentes... mais il faut s’entendre sur ce que cela veut dire.
J’ai été témoin de deux mises en production dramatiques récemment *
1️⃣ Un upgrade #Odoo 15 a flingué la performance des sites d’un client. Un petit patch de sécurité ralentissait exprès l’authentification API. Galère. Impossible de faire marche arrière : le patch faisait partie d’un ensemble plus grand de changements, et la cause n’était pas identifiée au début.
2️⃣ Une migration d’un serveur dédié vers le cloud tourne au cauchemar. Un logiciel bourré de N+1 queries quand on ajoute de la latence réseau entre le code et la DB, c’est l’enfer tapi dans l’ombre qui s’exprime d’un seul coup.
Dans les deux cas, le prestataire tech a fait un paquet d’heures supplémentaires, et a été obligé de faire un geste commercial **
Entendons-nous : les mises en production fréquentes que je prône ne ressemblent pas à cela. Ici, il s’agit d’une mauvaise gestion des risques et ce n’est pas du tout la même chose.
La mise en production fréquente c’est un mécanisme qui ne s’applique que quand les risques sont faibles et/ou cadrés.
Faire des gros déploiements de code écrit par d’autres, ou changer drastiquement d’infrastructure, sans tests fonctionnels automatisés ni tests de charge, c’est un gros risque mal cadré.
#SoftwareEngineering #Agile
- "témoin" : dans l’une d’elle j’ai une petite part de responsabilité ; je m’excuse platement auprès des personnes concernées.
** merci aux hard workers et autres sauveurs appelés à la rescousse.