Vous en avez assez de patienter deux mois pour livrer en production ? Vous souhaitez fluidifier les livraisons de votre entreprise en faisant collaborer Devs et Ops ?
Bravo ! Mais une fois n’étant pas coutume, plutôt que de prêcher la bonne parole, nous allons parler des erreurs souvent commises et voir ensemble comment les éviter.
Découvrez avec nous cinq anti-patterns DevOps courants.
Anti-Pattern numéro 1: L’outil magique
Le premier Anti-Pattern dont nous allons parler est également le plus courant (malheureusement). Il consiste à confondre DevOps avec automatisation et donc à ajouter un outil permettant de déployer automatiquement les systèmes.
Disons le tout de suite il n’existe pas d’outil magique fluidifiant comme par magie le processus de mise en production.
Si l’idée de cet outil provient des équipes de développement, les opérationnels penseront qu’on veut les remplacer. Au contraire si l’idée vient des opérationnels, les développeurs se sentiront peu (voir pas du tout) impliqués.
Anti-Pattern numéro 2 : L’équipe merveilleuse
Quasiment aussi courant que l’Anti-Pattern « j’impose un outil » voici l’Anti-Pattern « L’équipe merveilleuse » aussi connu sous le nom de « Je crée mon équipe DevOps ».
Il consiste tout simplement à créer une équipe dédiée à la mise en place d’une démarche DevOps au sein de l’entreprise.
Un principe fondateur de cette démarche est de faciliter le passage du logiciel de l’équipe de développement à la mise en production et de pouvoir livrer des fonctionnalités rapidement. Ajouter une nouvelle équipe n’est pas la bonne façon de faire, sauf à imaginer que cette nouvelle équipe soit en charge de l’amélioration des pratiques et de la transformation des autres équipes.
Le but de DevOps est de supprimer les silos pas d’en créer un nouveau.
Anti-Pattern numéro 3 : L’histoire sans fin
Afin de faire émerger une culture commune dédiée à livrer de la valeur en production, il est nécessaire que chaque équipe implique l’autre et cela dès le début du projet.
Une étape importante dans tout projet Agile est de choisir une Definition of Done qui aide chaque membre de l’équipe de développement à comprendre ce qui est nécessaire pour considérer une tâche comme terminée.
Cela oblige à inclure les Ops dans le projet, à ajouter une étape dans votre management visuel et à vous préoccuper du devenir de vos User Stories une fois le développement terminé. Et la réciproque est également vraie pour les administrateurs systèmes; Avoir un beau script automatisant un déploiement sur son PC n’est pas suffisant. Ce script doit être disponible dans le gestionnaire de source, compréhensible, modifiable et exécutable par d’autres, en particulier l’équipe de développement.
Anti-Pattern numéro 4 : Chez moi ça marche
De la même façon que les développeurs se doivent d’inclure les opérationnels dans leurs processus le contraire est également vrai.
Cela permet d’éviter des dialogues extrêmement constructifs de type :
« – La dernière version est lente en production !
- Ah bon ? Chez moi ça marche… »
Cette réponse trop souvent donnée par les développeurs provient principalement d’un manque d’information sur ce qui se passe réellement en production. Et pour corriger cela il faut partager, échanger, comme toujours.
Les Ops peuvent par exemple partager les différents indicateurs de santé de la plateforme avec les développeurs sous forme de dashboards.
Sur le même principe les développeurs peuvent être notifiés en même temps que les Ops en cas de problème sur la plateforme (ce qui incitera également à ne pas mettre tous les logs au niveau Error ou Critical…)
Enfin il est également souhaitable de mettre en place des tests de performance en continu sur un environnement de pré-production toujours dans le but de partager des métriques communes entre les équipes opérationnelles et de développement.
De manière plus générale chaque personne de l’équipe doit se sentir responsable des fonctionnalités livrées à l’utilisateur. Problèmes de code, problèmes d’infrastructure doivent avoir le même résultat: chacun doit se sentir concerné.
Anti-Pattern numéro 5 : Nous sommes uniques
Un autre classique, nous ne pouvons pas mettre en place DevOps, nous sommes uniques. Notre entreprise est tellement particulière que ces nouvelles techniques ne fonctionneront pas.
Oui, mais c’est le cas de tout le monde. Chaque entreprise à ses particularités, ses individualités différentes et ses problèmes. Et donc à cause de cet état d’esprit on continue à travailler, toujours de la même manière, toujours avec les même problèmes.
Il faut bien se rendre compte que les principes DevOps sont appliqués dans un grand nombre d’entreprises, petites ou grandes et même au sein de gouvernements (par exemple celui du Royaume-Uni). Bien évidement changer une culture d’entreprise n’est pas une tâche simple et aisée. On ne peut pas arriver un lundi matin et se dire, aujourd’hui mon entreprise passe à DevOps. Cela prend du temps et se fait par incrément.
L’idée principale est de commencer petit afin de construire de la confiance et montrer que cela fonctionne sur un petit projet pilote. De plus il est plus aisé de convaincre le management d’appliquer cela sur un petit projet, représentant moins de risques que de débuter directement par le projet critique pour la survie de l’entreprise.
Une fois que l’on a un projet pilote il est très important de mettre en place des métriques, c’est une idée essentielle de DevOps, mesurer. Il faut trouver des KPI représentatifs du changement et permettant de le suivre. Ces KPI sont également très utiles pour communiquer sur le projet et sur l’application de DevOps. Appuyer son histoire DevOps sur des données chiffrées est toujours plus convaincant et objectif que de l’appuyer sur des sentiments.
Si tout se passe bien et que vous communiquez régulièrement sur votre projet (via les indicateurs et votre histoire) celui-ci devrait commencer à attirer des personnes curieuses. Il faut dégager du temps pour elles afin d’expliquer la méthode, les difficultés rencontrées sur votre projet et les bénéfices apportés par la méthode.
L’amélioration continue est également une part importante du processus de transformation. Vous allez rencontrer des problèmes. Il est essentiel d’apprendre de ces problèmes et de retirer (ou d’automatiser) les étapes ne créant pas de valeurs suivant une démarche typiquement Lean.
Ainsi petit à petit même votre entreprise totalement unique pourra effectuer sa transformation.
Conclusion:
La démarche DevOps ne se résume pas à une démarche d’automatisation ou à une équipe de développeurs DevOps faisant le travail des opérationnels. Il s’agit d’un ensemble de pratiques humaines ayant pour but de livrer des logiciels en production de façon rapide, sûre et mesurable.
Celles-ci peuvent être résumées par l’acronyme CALMS:
- Culture : privilégier les personnes et les interactions plutôt que les process ou les outils ;
- Automation : l’automatisation est primordiale pour faciliter les installations afin d’obtenir des retours rapides d’une nouvelle version ;
- Lean : utiliser les principes Lean (débuter petit, identifier les processus amenant de la valeur, amélioration continue) afin de diminuer le temps de cycle ;
- Measurement : mesurer tout ! Cela permet d’aligner les équipes via des métriques communes et partagées ainsi que de voir les points de blocage empêchant un feedback rapide ;
- Sharing : créer une culture où les personnes partagent des idées, des outils,…
Bon courage !