Skip to content

Christophe Rochefolle

Experienced IT executive providing tech & organization to improve #quality & #agility of IT systems, #ChaosEngineering fan ; #LGBTQ+ #DiversityInclusion

Menu
  • Accueil
  • Présentation
  • Valeurs
  • Ouvrages
  • Conférences
  • Lectures
  • Images inspirantes
  • Contact
  • English
Menu

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

Posted on 5 octobre 20194 janvier 2020 by Christophe ROCHEFOLLE

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 !

Partager :

  • Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)
  • Cliquez pour partager sur Facebook(ouvre dans une nouvelle fenêtre)

Articles similaires

1 thought on “#DevOps : Et si on déployait aussi le vendredi ?”

  1. Ping : CLOUD EXPO EUROPE/DEVOPS LIVE 2022 - Christophe Rochefolle

Laisser un commentaire Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Suivez-moi

Tweets

On m’a déjà fait comme retour que je suis trop “gentil” dans mon management - 1/ c’est mal me connaître, je suis adepte du “praise in public, criticize in private”, 2/ à priori c’est un atout pour la productivité des équipes welcometothejungle.c…

Il y a 5 jours De Christophe Rochefolle @crochefolle@fosstodon.org's Twitter via Twitter for iPhone

RT @jocelyngriselle @FlutterFrance @SNCFConnectTech Une vidéo amateur de notre envoyé spécial semble indiquer que le cameraman du Flutter Forward avait des parts chez Train Line et a volontairement détourné la camera #onnousment #freesncfconnect #probablementunreptilien twitter.com/nosseste…

Il y a 6 jours De Christophe Rochefolle @crochefolle@fosstodon.org's Twitter via Twitter for iPhone

RT @FlutterFrance Il fallait être trèèèès attentif/attentive pour arriver à voir @SNCFConnectTech qui a été diffusé hier au #FlutterForward pendant à peu près 2 secondes 🚅 pic.twitter.com/HBQM…

Il y a 6 jours De Christophe Rochefolle @crochefolle@fosstodon.org's Twitter via Twitter for iPhone

RT @t3dotgg When you open your website on Safari for the first time pic.twitter.com/fxGX…

Il y a 6 jours De Christophe Rochefolle @crochefolle@fosstodon.org's Twitter via Twitter for iPhone

RT @SNCFConnectTech Stay tuned ! Nous devrions faire une apparition au #FlutterForward avec notre application tout-en-un des mobilités durables #SNCFConnect développée sur #Flutter par nos #DigitalMobilityChangers twitter.com/FlutterF…

La semaine dernière De Christophe Rochefolle @crochefolle@fosstodon.org's Twitter via Twitter for iPhone

Enjoy and bring back pictures and good news to share with our #DigitalMobilityChangers @SNCFConnectTech twitter.com/nosseste…

La semaine dernière De Christophe Rochefolle @crochefolle@fosstodon.org's Twitter via Twitter for iPhone

Très heureux de démarrer l’année en accueillant le retour 2 ans après du meetup @FlutterParis twitter.com/SNCFConn…

Il y a 2 semaines De Christophe Rochefolle @crochefolle@fosstodon.org's Twitter via Twitter for iPhone

RT @SNCFConnectTech C’est parti pour le Meetup @FlutterParis ! Au programme : 2 conférences #tech et un #live par les équipes @SNCFConnectTech. Suivez l’événement en direct sur ce #thread 👇 pic.twitter.com/ddD0…

Il y a 2 semaines De Christophe Rochefolle @crochefolle@fosstodon.org's Twitter via Twitter for iPhone

RT @SNCFConnectTech Nos experts #Flutter vous donnent RDV le 17/01 prochain à 19h dans nos locaux pour le Meetup @FlutterParis ! 📅 Inscriptions et programme ⤵️

Il y a 3 semaines De Christophe Rochefolle @crochefolle@fosstodon.org's Twitter via Twitter for iPhone

Le train est un choix, pas uniquement parce que je bosse dans une filiale du groupe SNCF, pas uniquement parce que mes 2 grand-pères y travaillaient mais surtout car c’est un moyen de transport eco-responsable 🌳🌳🌳 #monAnneeSncfConnect #sncfconnect pic.twitter.com/Z5EW…

Le mois dernier De Christophe Rochefolle @crochefolle@fosstodon.org's Twitter via Twitter for iPhone

Articles

  • Chaos (6)
  • Conférences (2)
  • DevOps (4)
  • Management & LeaderShip (3)
  • Non classé (2)
  • Qualité & Excellence (6)
  • Valeurs (4)

Abonnez-vous

Rejoignez les 3 autres abonnés
Confidentialité et cookies : ce site utilise des cookies. En continuant à naviguer sur ce site, vous acceptez que nous en utilisions.
Pour en savoir plus, y compris sur la façon de contrôler les cookies, reportez-vous à ce qui suit : Politique relative aux cookies
© 2023 Christophe Rochefolle | Fourni par Superbs Thème de blog personnel
 

Chargement des commentaires…