La boîte à outils DevOps, ce qu’il y a dedans va vous surprendre…

Suite à la publication d’un article sur ce qu’est DevOps (et ce qu’il n’est pas), un commentaire est à porter sur l’infographie suivante, présentée comme des outils DevOps :

 

On y retrouve un certain nombre d’outils, utilisés quotidiennement par de nombreux acteurs IT, qui permettent ou améliorent le travail collaboratif pour certains, l’automatisation pour d’autres, la gestion de versions de code, la gestion de configuration etc.

La question est donc de savoir si ces outils peuvent-être considérés comme DevOps ou non.

 

Didier, Fadia et Joann… utilisateurs d’outils “devops”

Didier est Développeur. Il appartient à une équipe qui travaille sur un produit “P”. Cette équipe a son “PO” dédié, son “Scrum Master” dédié. Le code est poussé sur un dépôt Git, puis Didier exécute une pipeline Jenkins pour “builder” son composant, son image Docker, qui sera ensuite déployée dans un cluster Kubernetes.

Fadia est Intégratrice. C’est elle qui est chargée de créer le/les pipelines pour les équipes de Développeurs en fonction de leurs besoins (Créer des buckets Couchbase, et ajouter les configurations dans le pipeline, permettre au pipeline d’utiliser SonarQube pour les tests automatisés, etc). L’équipe de Fadia recevant des demandes de différentes équipes de développement gère son backlog selon les principes Kanban. Chaque personne prend des tâches qui sont demandées à l’équipe d’intégration. L’équipe de Fadia a son “PO” et “Scrum Master” dédié. L’équipe de Fadia fournit du service à l’équipe de Didier.

Joann est lui, dans l’équipe de production. Il s’occupe de l’exploitation des solutions développées par la société dans laquelle travaillent Didier, Fadia et Joann. Il s’occupe du bon fonctionnement des applications, voire de l’évolution des pipelines mis en place par l’équipe de Fadia. L’équipe de Joann, du fait de ses contraintes de production travaille selon les principes Kanban. Un référent est associé à chaque équipe de développement pour assurer une meilleure gestion des incidents et des évolutions. L’équipe de Joann n’a pas de “PO”, mais a un “Scrum Master” dédié.

On voit bien que les outils utilisés sont inclus dans l’infographie. Pour autant, on est très loin de DevOps. Toutes les équipes sont silotées, ne partagent pas les objectifs, et n’ont pas réellement de gouvernance commune.

 

Le marteau ne fait pas l’artisan, les outils d’automatisation ne font pas le DevOps

Il y a quelques années, j’ai reçu pour Noël une superbe boîte à outils, contenant perceuses, marteaux, tournevis, scies… Et pourtant, dès que j’ai des travaux à faire à mon domicile, je suis souvent obligé d’appeler mon père à la rescousse. J’ai beau avoir tous les outils du parfait bricoleur… ça ne fait pas de moi un bricoleur. Je n’ai jamais appris, je ne sais même pas choisir le bon foret en fonction du mur que je dois percer.

Pour DevOps c’est pareil, vous avez beau avoir tous les outils de l’infographie ci-dessus, si vous n’avez pas appris à travailler selon la philosophie DevOps, vous risquez comme moi avec mon mur, de faire de sacrés dégâts : pas de prise en compte de l’aspect sécurité au moment du développement, des tests automatisés, de la production, du temps de mise sur le marché, de la qualité produit.

C’est au moment du lancement du produit qu’on s’aperçoit que les logs sont mal formatés et mal pris en charge dans le concentrateur de logs et qu’il est difficile de créer des tableaux de bords ou des alertes efficaces.

On s’aperçoit également que le cycle de vie et le patch management n’ont pas été implémentés, que l’application n’est pas assez bien testée et que de gros problèmes de fond vont présenter des risques.

Le temps passé à corriger ces problèmes de fond risque de faire passer le produit à côté de son marché potentiel, une application concurrente étant arrivée entre temps et proposant une offre ayant séduit votre cœur de cible. Et si tout cela avait pu être évité dès le commencement du projet ?

 

Scrum, un exemple de boîte à outils DevOps

Contrairement à ce qui est répandu un peu partout, Scrum N’EST PAS une méthode, ni moins une méthodologie Agile.

Tout d’abord, ce n’est pas une méthode ou méthodologie, car c’est un cadre de processus léger, une sorte de boîte à outils proposant des pratiques recommandées et n’imposant que peu de choses comme ses rôles, et ses cérémonies, qui permettent le mieux travailler ensemble.

D’autre part, Scrum n’est pas Agile, car ce cadre de processus est apparu plusieurs années auparavant et a été conçu pour le développement, la livraison et la maintenance de produits complexes, y compris donc les projets non-informatiques. Il est donc possible d’utiliser Scrum dans le cadre du développement d’une fusée ou d’une campagne marketing.

 

Mais alors pourquoi proposer Scrum comme boite à outils DevOps, si Scrum n’est pas Agile ?

Lors de son intervention à Agile en Seine 2018, Guillaume Lepetit, ancien DSI de TF1 qui a mis en place DevOps dans ce groupe média, avait eu cette phrase délicieuse : “Ils (les collaborateurs) n’allaient pas pouvoir faire du DevOps sans avoir les bases de l’Agilité.”.

Or d’après Diana Larsen et James Shore, auteurs du Modèle d’Aisance Agile, la première zone à franchir pour qu’une organisation devienne Agile, est la zone dite de Concentration (“Focusing”). C’est dans cette zone que l’on va se concentrer sur la production de valeur métier. Elle s’appuie notamment sur l’apprentissage qu’une équipe peut tirer de Scrum.

Les spécificités de Scrum sont donc toutes indiquées pour qu’une équipe puisse commencer à mettre DevOps en place :

En Scrum, il est nécessaire pour une équipe de regrouper l’ensemble des compétences essentielles au développement du produit. Ce qui veut dire pas seulement les Devs, pas seulement les Devs + les Ops, mais aussi les personnes compétentes en monitoring, en sécurité, voire en UX également. Peut-être que certaines compétences seront moins nécessaires sur certains sprints. Dans ce cas, les personnes ayant ces compétences seront intégrées dans l’équipe de développement sur les sprints où ces compétences seront utiles.

Il faut bien comprendre que équipe de développement ne veut pas dire “équipe de Développeurs”. L’autre notion à retenir, c’est que c’est toujours l’équipe dans son ensemble, qui est responsable de l’incrément produit potentiellement livrable, peu importe les profils qui la composent. Les Devs, les Ops, les Secs sont tout autant responsables de l’incrément produit.

Il n’y a donc qu’un seul backlog pour l’ensemble des tâches, DEV, SEC, OPS, QA, l’équipe partage les même objectifs et chacun de ses membres doit être aligné sur la même vision produit dont le PO a la charge.

Scrum s’appuie sur 3 piliers : Transparence, Inspection et Adaptation.

Ainsi l’une des cérémonies les plus importantes en Scrum est la rétrospective. Elle permet à l’équipe, à chaque fin de sprint, de réfléchir à l’amélioration continue du travailler ensemble, en se basant sur les expériences passées.

L’équipe Scrum acquiert donc, sprint après sprint, une culture commune, de la transparence et du partage, basés sur les mesures du passé. Et puisqu’elle doit être en mesure de pouvoir livrer l’incrément du produit fini (répondant à tous les critères d’acceptation à chaque fin de sprint), l’automatisation et la sécurité en sont donc des pré-requis.

Scrum permet de mettre en place facilement les 4 piliers DevOps, c’est pourquoi ce cadre de processus peut être considéré comme boîte à outils DevOps.

En mettant en place Scrum, Didier, Fadia et Joann vont donc se retrouver dans la même équipepartager les même objectifs, avec un backlog unique,un seul PO et un seul Scrum MasterIls travailleront enfin ensemble et non séparés et deviendront DevOps.

 

Vincent, Lead de la Communauté Métier Ops @Extia

top

Tous droits réservés.