Sortie du troisième et dernier volet de la trilogie Culture DevOps – Interview de Victor Mignot & Arnaud Mazin, auteurs de Culture DevOps Vol.03

Le volet “Culture DevOps : à la découverte des pratiques de qualité pour une infrastructure à l’épreuve du temps” vient terminer notre trilogie DevOps rédigée avec amour par nos consultants. Une belle occasion pour revenir sur l’initiative de départ et leur donner l’opportunité de partager leur vision du marché.

Le troisième et dernier volet de la trilogie met la qualité au centre de notre démarche DevOps. L’autonomie et les nouvelles technologies données aux équipes produit permettent de fluidifier le passage en production, mais attention : le but n’est pas de déployer plus vite des dysfonctionnements. Il s’agit une fois de plus de favoriser une culture de la qualité, grâce à des rituels et des outils, que nous vous présentons. 

La culture et le craftsmanship associés à la technique est le seul moyen de garder la maîtrise et la qualité.”, résument Arnaud Mazin et Victor Mignot, auteurs de Culture DevOps vol.03. 

Mais encore ?

Télécharger Culture DevOps Vol.03

Culture DevOps 3 : comment vient-il conclure la trilogie ? 

Dès le commencement de l’aventure nous savions que nous allions aborder les 3 aspects majeurs de la transformation DevOps. Il était important pour nous, pour nos convictions, de débuter par la partie “Culture” qui est le socle de toute la démarche. Dans le second tome, nous voulions appuyer notre amour de la tech : c’est un aspect à ne pas oublier. Le volet 3 insiste plus sur la qualité.

La culture et la technique doivent absolument s’inscrire dans une démarche de qualité sinon c’est aller droit dans le mur. La technique est un vrai levier de transformation dans DevOps. Mais nous avons la conviction que si la technique est mal utilisée, c’est-à-dire si elle n’est utilisée uniquement en tant qu’outils, c’est le meilleur moyen de se planter. L’objectif de ce dernier volet est de synthétiser notre propos : associer la culture et le craftsmanship à la technique est le seul moyen de garder la maîtrise et la qualité.

Dans quelle mesure cet ouvrage vient-il compléter la “démarche qualité” amorcée par l’ouvrage Culture Code ?

Nous avons tendance à dire que “le DevOps c’est de l’agilité jusqu’à la production” et Culture Code le confirme en plaçant la qualité autour de tout ce qui est production de code. Dans notre ouvrage, nous voulions avertir sur la qualité qui ne doit pas s’arrêter seulement au packaging d’applications fait par le développeur mais qui doit aussi aller jusqu’à la production. Culture Code nous a donc épaulés tout au long de la création de ce troisième tome, car il nous rappelle tout ce que les développeurs ont déjà réussi à mettre en place.

Culture Code est notre ouvrage de référence chez OCTO : tout a été dit. Avec Culture Devops nous venons titiller les spécificités qui n’ont pas été détaillées, liées au fait que nous faisons de l’infrastructure, de “l’infra as code”, de la production.

Pour vous, en appliquant tout ce qu’il y a dans ce volume, est-on sûr de faire du code de qualité chez nous ?

Non. Ce n’est pas aussi simple malheureusement. Nous sommes d’accord que c’est un message qui est à la fois facile à dire et pourtant très rarement appliqué. Nous mettons beaucoup de choses dans nos livres blancs, beaucoup de contextes, de petites histoires issues de notre expérience en mission chez nos clients. Mais ces recommandations sont bel et bien génériques… Là où votre entreprise est unique, elle. Culture Devops c’est un peu la manière de vous rentre compte que vous n’êtes pas les seuls à rencontrer vos problèmes… mais qu’il faut ajuster l’ensemble des solutions que l’on préconise à vos particularités.

Notre meilleur conseil est de vous inviter à identifier les points sur lesquels vous souhaitez vous améliorer, et d’implémenter telles quelles (dans un premier temps) nos recommandations sur un périmètre restreint. Puis de rentrer dans une démarche d’amélioration continue : vous aurez alors un regard critique sur ce  vous voulez implémenter. Il est nécessaire d’ajuster en permanence pour que vos solutions soient les plus adaptées à votre écosystème et votre manière de travailler.

Les outils autour de la qualité dans l’IaC sont également une source de frustrations perpétuelles : ils sont encore peu nombreux et il y a beaucoup de place pour de l’amélioration.

En quoi cet opus est en rupture avec les pratiques communément observées dans les équipes de production ?

Nous faisons un jugement un peu dur mais c’est volontaire, car d’un point de vu historique la production a toujours été dans l’urgence et surtout a toujours eu beaucoup de responsabilités. Si quelque chose se passe mal, c’est souvent aux Ops que l’on demande des comptes. Ce sont des équipes qui développent des réflexes défensifs car elles doivent mettre beaucoup de choses en place pour de la stabilité.

Ainsi nous voulons faire bouger les lignes et inciter les équipes à intégrer de la qualité dans les cycles courts de développement en misant sur la sécurité, l’observabilité et tout ce que l’on dit dans nos white papers

Nous avons également constaté que le changement de paradigme est plus compliqué pour les Ops “canal historique”. En effet, ils ont plus de mal à adopter des habitudes que leur apporte les développeurs sur la gestion de code de qualité. Nous avons le sentiment que c’est plus facile pour un développeur de devenir DevOps que pour un Ops “pure souche” d’aller vers des pratiques “Dev”.

Maintenant que la trilogie est terminée, qu’est-ce qu’il va se passer dans le DevOps ces prochaines années ?

Il y a déjà 2 tendances qui ont déjà pris la suite de DevOps : la tendance DevSecOps, portée par notre tribu AppSec qui vient appuyer sur le fait qu’il est nécessaire d’augmenter la sécurité au cœur de cette démarche continue. Puis tout ce qu’inspire le livre Accelerate qui fait écho à ce que nous abordons déjà dans DevOps depuis maintenant bon nombre d’années, avec une approche totalement en phase et alignée. Le livre vient alimenter la tendance en s’appuyant sur des des métriques et des chiffres concrets. Notamment avec les 4 métriques types pour mesurer la performance d’une organisation (Deployment frequency, product delivery lead time, mean time to repair et change failure rate). 

Nous avons également l’espoir que les défauts de jeunesse de certains outils ou technologies vont se gommer et nous faciliter encore plus nos vie. Il faut maintenant espérer que l’on ait une convergence et une standardisation de ces outils ainsi qu’une appropriation des développeurs.

Télécharger Culture DevOps Vol.03


Pour aller plus loin…

Retour sur notre Matinale pour éclairer et rendre activable l’étude Accelerate qui démontre, chiffres à l’appui, que la performance logicielle est déterminée par la faculté à livrer le plus souvent possible :
Le compte-rendu
Les slides de la présentation
La vidéo en live


Laisser un commentaire

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


Ce formulaire est protégé par Google Recaptcha