S’il y a bien une question qui revient quand j’explique ce qu’est le DevOps, c’est « ok, mais comment on fait ? ». Parce qu’effectivement, il n’y a pas de bible qu’on suivrait à la lettre, pas de guide ni de méthode ; d’une certaine façon, c’est cela qui constitue le terreau nourricier de la mécompréhension, voire du détournement du terme. Cet article vise donc à proposer une méthode d’initiation du mouvement DevOps, en partant du modèle productiviste habituel.

Comme je l’expliquais dans l’article La roadmap pour devenir un DevOps, ce mouvement est constitué de 4 fondamentaux : la culture, l’automatisation, la mesure et le partage. Ces fondations proviennent de l’identité même du DevOps, à savoir appliquer la philosophie Agile sur toute la chaîne de production technique. Seulement voilà, on ne peut rien faire avec ces quelques mots, comme s’ils n’étaient que des grandes idées sans aucun lien tangible avec la réalité.

Parmi ces 4, la fondation des fondations est la culture puisque l’approche DevOps est un nouveau paradigme organisationnel. Nous allons donc utiliser la culture comme angle d’attaque pour amorcer la transformation vers le DevOps. Pour ça nous devons en apprendre un peu plus sur elle.

Comment on change une culture ?

Guy Rocher donne à la culture la définition suivante :

Un ensemble lié de manières de penser, de sentir et d’agir plus ou moins formalisées qui, étant apprises et partagées par une pluralité de personnes, servent, d’une manière à la fois objective et symbolique, à constituer ces personnes en une collectivité particulière et distincte.
~ G. Rocher¹

Thomas Hoult, lui, complète cette définition en la constituant de valeurs, de normes, d’institutions et d’artéfacts. Autrement dit, c’est ce qu’on partage et ce qui fait de nous un groupe, via un système de croyances, d’actes et de structures de diffusion. Le défi à relever est donc là : changer la culture remet en question l’identité même d’un groupe (ici, l’entreprise) et nous prenons le risque de le désagréger s’il est mené au forceps.

Par son système de couches successives, le « Modèle Oignon Agile »² est une bonne façon de représenter cela. Il établit que les outils peuvent être adoptés de façon directive mais n’altèrent que la surface du sujet ; les niveaux profonds, eux, requièrent des mutations structurelles inter et intra-personnelles pour réellement appliquer la méthodologie. Il en est de même pour le DevOps, puisque ce mouvement est une sous-branche de l’Agile. De ce fait, un premier élément de réponse apparaît : pour changer une culture, il est important d’avoir un management à la hauteur des enjeux, à la fois pour aller dans la bonne direction, mais aussi et surtout pour accompagner les équipes et répondre aux résistances. En bref, prendre soin des membres du groupe.

Alors, comment accompagner ? Pour réduire au maximum les frictions, il est nécessaire de privilégier l’approche consistant à partir de ce que les équipes ont déjà, puis de faire effet de levier pour l’extension de ces acquis. Pourquoi ? Parce que c’est l’intégration d’une équipe tierce qui recombine les sous-cultures initiales pour les mutualiser et ainsi redéfinit la notion de groupe, pas l’inverse.

Pour initier cette transformation venant de l’intérieur, la culture pré-existante doit satisfaire deux critères :

1. Être génératrice de valeurs compatibles avec le DevOps,
2. Être conservée tout au long du process.

En tant que système de gestion de version, Git a profondément changé la façon dont les développeurs travaillent. Finis les changements destructifs, les bugfixes qui empirent la situation et les duplicatas de répertoires 20240517_real_bugfix_x83756 pour palier tout ça. De nos jours, aucun développeur n’imagine plus travailler sans et une culture de la qualité du workflow s’est construite autour de cet outil. C’est comme ça qu’on travaille. Cette culture est composée de :

• valeurs : l’auditabilité favorise la relecture du code, la non destructivité par les commits permet la réversibilité et la traçabilité ;
• normes : nous faisons des branches séparées pour découpler le travail de chacun, nous débattons du code avant fusion et partageons sa paternité après ;
• institutions : les plateformes Git soutiennent les valeurs et normes en les intégrant au cycle de vie de production des logiciels ;
• artéfacts : le modèle de branche produit divers niveaux de qualité et livrables pour les environnements par la CI/CD/CD.

Comme on peut le constater, Git remplit toutes les conditions pour être une bonne culture d’amorçage, voyons donc comment nous pouvons nous y prendre.

Partir de Git pour une amorce en spirale vers le DevOps

Si Git est aussi populaire³, c’est parce que l’outil satisfait un besoin chez les Dev. Or, les Ops ne sont pas bien différents ; eux aussi veulent produire quelque chose de fiable, eux aussi veulent de la traçabilité, et eux aussi veulent versionner leur production pour visualiser la correspondance avec le logiciel.

La première étape de la méthode consiste donc pour l’équipe des développeurs à partager son fonctionnement basé sur Git auprès de l’équipe Ops afin que cette dernière se l’approprie pour son propre usage. Suite à cette première étape, les deux équipes se retrouvent avec un vocabulaire et des méthodes de travail communes (y compris la plateforme Git).

Cette convergence amplifie la culture autour de Git puisqu’elle la fait déborder au-delà de ses frontières originelles, participant à fragiliser le silo inter-équipes. Cela offre un terrain favorable à une nouvelle forme de communication : les équipes ont désormais un lieu central et des mots pour échanger sur les contradictions de l’application des enjeux de l’entreprise. Et surtout, un outil commun pour les atténuer.

La deuxième étape fait apparaître l’équipe Ops au sein des réunions où auparavant seule l’équipe Dev allait. L’objectif est d’entériner l’idée que la solution technique n’est pas seulement applicative, mais également infra et que ces deux sont fortement couplées ; à ce titre, l’équipe Ops prend le rôle de conseiller. Les métriques ne sont ici pas encore obligatoires à ce stade, mais les vérifications d’adéquation héritent naturellement des deux corps techniques.

L’étape trois enclenche la spirale, c’est à partir d’elle que la production se ré-organise : abreuvés des conseils infra, les tickets se précisent et tiennent désormais compte du contexte système pour satisfaire toutes les exigences.

NB: Cette réécriture des tickets est une nécessité pour diluer les paradoxes inhérents au modèle organisationnel historique dans la réponse commune des corps techniques. Elle empêche tout retour arrière accidentel.

En réponse à cette réécriture, le management change l’organisation du travail :

• la production technique inclut le développement infra pour synchroniser les altérations et adapte son séquençage pour éviter les temps morts,
• la notion de livrable versionné mute pour intégrer toute la pile,
• si le besoin se fait sentir, les équipes sont recomposées en feature teams tout en garantissant des communautés de pratiques par pôle technique.

Cette restructuration pousse inexorablement les Ops à accélérer la manipulation de l’infra sans transiger sur la fiabilité : la pratique de l’infra as code apparaît.

Où cela nous mène ?

Le DevOps est une démarche constante et sans ligne d’arrivée. Par contre, la méthode que je propose ici lui donne un point de départ : on fait travailler les développeurs un peu comme des Ops, les Ops un peu comme des développeurs, et c’est ce binôme qui impulse de proche en proche le changement aux autres équipes en montrant la valeur apportée.

Changer la culture ne peut se faire que de l’intérieur et c’est ce que nous faisons ici de façon bottom-up, en aucun cas il n’est possible de décider unilatéralement « vous allez faire du DevOps ». À la place, nous remettons le partage et la communication au cœur de la solution technique et nous commençons par Git. Il devient une source unique de vérité où tout devient du code, grâce à quoi tout technicien a tout ce qu’il faut pour automatiser toutes les autres pratiques.

Mais le chemin ne s’arrête pas là. Pour véritablement se diriger vers une application correcte du DevOps, des mesures et autres SLIs sont importants pour s’assurer de la bonne qualité du système conçu par les techniciens. Et si en guise de premières mesures nous commencions par créer celles qui montrent aux décideurs l’efficacité du DevOps ?