Jean-Michel, il a encore cassé la prod !
Ou comment dédramatiser les mises en prod ratées
Le rapport que nous avons avec les mises en production semble beaucoup évoluer au fil de notre carrière : lorsqu’on débute le métier, et même parfois bien après, appuyer sur le gros bouton rouge peut donner des sueurs froides.
Et si quelque chose se passait mal ?
Et si notre code n’était pas si parfait ?
Et si le site tout entier tombait en rade par notre faute ?! 😱
Ces questions, vous vous les êtes sans doute déjà posées. Peut-être est-ce d’ailleurs toujours le cas aujourd’hui. Mais… pourquoi ?
La première raison est évidente : la conscience professionnelle. Nous voulons faire notre travail correctement et bien entendu que casser la production est l’antithèse de cet objectif.
Cela dit, j’ai constaté que cette crainte de mise en production est bien plus souvent présente chez les plus juniors. Cela signifie-t-il que les seniors ont moins de conscience professionnelle ?
Bien sûr que non, mais la réflexion un peu candide serait de se dire que les seniors sont simplement plus sûrs d’eux : plus d’expérience dans le milieu, donc plus sûrs de leurs compétences, donc moins de craintes pour mettre en prod. C’est sans doute vrai, mais c’est surtout plus compliqué que ça.
Outre la conscience professionnelle, deux points peuvent faire peur lorsqu’on casse la prod :
- le regard des collègues
- le process pour réparer dans l’urgence
Et si on prend un peu de recul… ce sont deux points que personne ne devrait craindre, vous ne croyez pas ?
Avez-vous confiance en vos collègues ?
C’est plus fort que nous : lorsque le code qu’on a écrit casse quelque chose, on ne peut s’empêcher de s’en vouloir.
C’est notre code, c’est donc de notre faute. Vrai ?
Faux !
Si le process de votre entreprise suit la norme de ce qui se fait dans l’industrie, il est peu probable que vous êtes le ou la seule tributaire du code que vous avez mis en production, même si c’est vous qui l’avez écrit.
Peut-être votre code a-t-il en amont été le sujet d’une analyse technique, peut-être l’avez-vous écrit en pair avec un de vos collègues…
Il est sans doute passé sous le regard vigilant de ceux qui ont fait la code review de votre pull request. Des Quality Engineers ont sûrement essayé de tout casser lors de la phase de tests sur vos environnements de staging, tandis que des tests automatiques ont sans doute tout vérifier de leur côté.
Bref, le point ici est que vous n’êtes pas le ou la seul(e) responsable du code que vous déployez en production : c’est une affaire d’équipe !
Lorsqu’un bug est détecté en production, ce n’est jamais la faute d’une seule et même personne : c’est l’équipe toute entière qui s’est ratée quelque part.
Alors oui, les développeurs aiment bien se charier entre eux. On aime bien dire que “Jean-Michel a encore cassé la prod”. C’est rigolo de se moquer gentiment de Jean-Michel, ça peut dédramatiser la situation tout en se rassurant soi-même. Mais… attention.
Peut-être que Jean-Michel le prend bien et rigole volontiers avec vous, mais cela peut instaurer une ambiance malsaine malgré vous. Un développeur peu sûr de ses compétences pourrait être effrayé de se retrouver à la place de Jean-Michel.
Si les taquineries sur le sujet sont un bon moyen de faire comprendre qu’il n’y a pas mort d’hommes et que casser la production n’est finalement pas si grave que ça, nous ne sommes pas tous sensibles de la même manière. Pensez-y.
L’important est d’instaurer un climat de confiance dans votre équipe. Il faut que tout le monde se sente à l’aise de faire des erreurs.
“It’s OK to fail”, comme on dit à OpenClassrooms !
Mais il faut garder en tête que casser la production ne reste pas anodin : il n’est pas acceptable que votre site soit indisponible trop longtemps, cela peut avoir de gros impacts sur la crédibilité et la réputation de votre produit. C’est pourquoi, afin de pouvoir être à l’aise sur l’idée de faire des erreurs, il est important que les corrections pour régler les problèmes soient faciles et rapides à appliquer.
Vient donc le point 2 : le process pour réparer dans l’urgence.
Avez-vous confiance en votre système de rollback ?
Lorsqu’une mise en production casse quelque chose, il est important de pouvoir agir rapidement et efficacement. Les actions à mener doivent être claires pour tous : prévenir l’équipe, lancer le déploiement de rollback, corriger le code défectueux… Peu importe votre process, il faut avoir en tête qu’il est généralement effectué dans l’urgence : il est donc primordial qu’il soit bien documenté, mais surtout bien dans la tête de tout le monde !
Si votre équipe sait précisément ce qu’il faut faire en cas de problèmes en production, la crainte de casser quelque chose sera naturellement amoindrie. La peur de l’inconnu est l’une des peurs les plus communes, alors faites en sorte qu’elle ne concerne pas votre processus de réparation de votre site !
Ce n’est qu’avec un système de rollback clair, efficace et non stressant qu’il est possible de dédramatiser les mises en production ratées.
À OpenClassrooms, on a tellement confiance en notre process qu’on n’hésite pas à déployer en production le vendredi… Et chez vous ?
Bon, OK, vous avez cassé la prod… Et après ?
Tout comme un boulanger peut brûler son pain, ou un peintre peut rater son coup de pinceau, un développeur peut écrire un code non fonctionnel.
Ça arrive, ça fait partie du métier !
Pour les plus juniors d’entre nous, sachez qu’on a tous fait des erreurs. Que ce soit moi, ce cher Jean-Michel, votre collègue trop fort qui vous impressionne, ou votre CTO… On a tous cassé une production au moins une fois dans notre vie professionnelle.
Lors de mon tout premier job, j’ai envoyé un e-mail de test à tous les clients de l’entreprise : confondre la base de staging avec celle de prod est une erreur classique et, croyez-moi, je n’ai fait cette erreur qu’une seule fois dans ma vie !
Autre exemple, à OpenClassrooms cette fois : mon propre manager avait cassé la route API publique retournant la liste de nos parcours. Et devinez quoi ? C’est aujourd’hui le directeur engineering de la boite !
Ce n’est pas parce que votre code a cassé quelque chose que votre carrière est terminée.
Mais ne me faites pas dire ce que je n’ai pas dit : casser la production reste quelque chose à éviter. Faire une erreur une fois de temps en temps n’est pas si grave, c’est répéter cette même erreur qui est problématique. Pensez au fameux dicton :
C’est en faisant des erreurs qu’on apprend.
Alors apprenez, apprenez tant que vous le pouvez !
Et soyez gentils avec Jean-Michel 😉
