#DevOps : Et si on déployait aussi le vendredi ?

Ou comment passer de la culture de la peur à celle de la confiance

Comme souvent, c’est la lecture d’un tweet de Charity Majors que mon rejet des règles « parce qu’on a toujours fait comme ça » a été inspiré et m’a invité à vous proposer cet article.

S’interdire de mettre en production le vendredi est un anti pattern  #DevOps

Bien plus que de rapprocher les devs des ops, la démarche DevOps a pour objectif de permettre de mettre à disposition de manière sûre toute fonctionnalité aussitôt qu’elle est développée et testée afin d’apporter la valeur générée au plus vite auprès des utilisateurs et ainsi avoir une boucle de feedbacks la plus courte possible.

S’interdire de déployer le vendredi, c’est se priver de 20% de temps où l’on peut apporter cette valeur à nos utilisateurs. Souvent on s’interdit également le jeudi après-midi, les veilles de jours fériés, on dépasse ainsi les 30%… 

Au delà de ce point déjà essentiel, on donne l’impression qu’on n’est pas sûre de notre pipeline de déploiement, de nos tests, que l’on a pas confiance dans nos équipes. Si vous n’avez pas confiance dans vos Mise en Production (MEP)  du vendredi, qu’est-ce qui fait que vous avez plus confiance les autres jours ?

Cette règle induit que faire une MEP est dangereux, risqué. On ne devrait pas avoir PEUR de mettre en production.

Si vous vous dites #DevOps alors vous devez pouvoir déployer quand vous le souhaitez, nuit comme jour, y compris le vendredi !

Pourquoi cette règle ?

Les cassandres vous diront que cette règle n’est pas là pour se faire plaisir, qu’elle est nécessaire si on ne veut pas se pourrir ses week-end. Que c’est du bon sens, un principe de précaution…

Et nous avons tous vécu des épisodes où nous l’avons vérifié. Il est donc difficile de se faire violence et de se dire que ce n’est pas la bonne approche.

Prenons un peu de recul. Qu’est-ce qui fait que nous regrettons les MEP du vendredi ?

1. La MEP qui se passe mal et qui vous fait rester tard le vendredi soir, voire le samedi matin.

Un des principes de bases de DevOps est qu’une MEP doit être un non événement technique. Notamment par la mise en place d’une pipeline industrialisée, avec des tests automatisés qui génèrent un niveau de confiance élevée pour envoyer en prod, voire aussi du blue green qui permet de revenir en arrière instantanément, etc… Il s’agit donc de développer la sûreté de fonctionnement de vos processus de construction et d’évolution d’applications et services. Sur le sujet, je vous conseille un excellent livre co-écrit avec mon ami Alain Sacquet.

2. L’incident qui se déclare quelques temps après la MEP qui doit être gérer par les astreintes.

Le vrai sujet ici est pourquoi ne détecte-t-on pas l’incident dès la fin de la mise en production ?

Bien sûr, la première chose est de s’assurer que l’équipe qui déploie surveille sa production après le déploiement. Il ne s’agit pas de déployer le vendredi à 18h et de partir aussitôt prendre une bière .

Ensuite, a-t-on le bon niveau d’observabilité permettant de détecter les prémisses d’un incident ? Tout démarche DevOps doit prendre en compte une démarche d’amélioration de l’observabilité, pour passer d’un monitoring basique à un moyen de détecter au plus tôt un comportement anormal de nos systèmes. Sur le sujet, je vous conseille le livre blanc de mes amis de chez D2SI, avec la participation de mon compère Benjamin Gakic.

Enfin, pourquoi l’incident serait-il géré par les astreintes. Une équipe responsable assume les risques pris et surtout les conséquences. Ainsi elle mettra tout en oeuvre, notamment les pratiques de sûreté de fonctionnement évoquées plus haut pour éviter de perdre ses nuits et week-ends.

3. L’imprévu, l’inconnu 

Charity Majors Chaos Engineering et Observabilité 

Et il y a évidemment les imprévus. On a déployé des centaines de fois sans aucun problème et cette fois-ci, ça plante. Un équipement tombe en panne. Un déploiement d’une autre application tombe exactement à la même seconde et touche un fichier de manière concurrente. Un serveur a un horodatage de quelques heures de différence et se croit déjà demain… Tous ces événements qui ne sont jamais arrivés et ne se reproduiront probablement plus.

Ils font partis des risques, probablement plus frustrant un vendredi soir. Mais va-t-on s’empêcher de sortir dehors car une météorite peut nous tomber dessus ?

La meilleure chose à faire est de s’y préparer au mieux, notamment à travers une démarche de Chaos Engineering.

En synthèse, avec un niveau de maturité DevOps suffisant, cette règle n’a plus lieu d’être.

Comment passer le cap ?

Vous aimeriez passer le cap et autoriser vos équipes à déployer, mais une petite voix vous bloque (probablement celle de vos boss ou du patron de la prod). Pourquoi ne pas mettre en place un permis de MEP ?

Le principe est simple. Si une équipe à un niveau de maturité suffisant :

• Des test automatisés avec une excellente couverture
• Une pipeline industrielle de déploiement de type « presse bouton »
• Du feature flipping pour activer/désactiver les nouvelles fonctionnalités
• La capacité quasi immédiate de retour arrière (par du blue-green par exemple)
• Si elle gère ses propres astreintes
• …

Ces propositions sont à adapter à votre contexte et à vos besoins.

Donc si elle a un niveau de maturité – selon vos critères – que vous estimez suffisant, plutôt qu’une interdiction par défaut, faites leur confiance par défaut en leur délivrant un permis de MEP 24×7.

Vous pouvez même pousser le concept en mettant en place aussi un système de point:

• Ne pas désactiver le système d’alerting qui va envoyer de fausses alertes pendant le déploiement: -1pt
• 3 MEP consécutives avec rollback : -3pts
• Lancer une MEP et partir aussitôt déjeuner/prendre une bière/en week-end : – 6pts
• …

Vous pouvez également mesurer la courbe de distribution des déploiements.

Cette courbe est un indicateur intéressant de maturité DevOps. Tout en s’assurant qu’elle n’est pas artificielle, qu’on ne « retient » pas une MEP quelques jours pour faire plaisir à un objectif d’entreprise. L’indicateur pertinent reste toujours la durée de « stock de code », le code développé et testé qui n’est pas encore mis face à son public.

Ainsi, en ôtant l’interdiction de déployer le vendredi et en instaurant un système de permis, on passe d’une culture de la PEUR/INTERDICTION à une culture de la CONFIANCE.

En bonus,en ces temps de difficulté pour recruter des profils tech, pouvoir communiquer que vous avez tellement confiance en vos équipes et process que déployer le vendredi fait partie de vos habitudes devraient être un argument pour attirer des talents !