Le DevOps n’est pas un outil ou une personne !
Actuellement, quand j’entends parler DevOps je suis choqué. Nombre de personnes se sont approprié le DevOps sans le comprendre. DevOps est devenu un de ces buzzwords qu’il faut utiliser et qu’il convient de placer dans une conversation. Une sorte de nouveau « Web 2.0 » qui succède à l’infâme « Agile ».
Oui « Agile » est devenu la nouvelle ambulance sur laquelle il faut tirer (du fait de l’avoir mal utilisé). DevOps c’est bien, Agile c’est nul.
Ce qui démontre que certains n’ont pas compris l’agilité et qu’ils ne comprendront peut-être pas mieux le DevOps. Si vous rencontrez une personne qui critique l’agilité au profit du DevOps, fuyez !
Au-delà du buzzword, il y a deux sujets qui nuisent au DevOps :
- La manière de parler des outils DevOps
- La création du rôle / poste de DevOps.
Prenons le temps de développer ces deux sujets, d’analyser le pourquoi, le comment, et de les rectifier.
Les outils
Nombre de personnes parlent de « l’outil DevOps » comme étant la solution à adopter, l’outil à acheter. Je comprends que certains veuillent vendre des licences, mais le DevOps, ce n’est pas un outil. Il s’agit d’une démarche à adopter. Un outil peut vous aider, mais ce n’est pas tout.
Avant d’adopter une démarche DevOps, il faut la construire. Établir des objectifs, des moyens, des manières de faire. Il faut ensuite les appliquer, déployer, tester, utiliser et contrôler les impacts positifs ou négatifs. Ensuite on revoit les objectifs, moyens et manière de faire…
La démarche est donc itérative et évolutive. Tout comme le ou les résultats produits. Ce n’est pas pour rien que l’on utilise souvent le symbole de l’infini pour expliquer DevOps.
Le DevOps n’est donc pas une démarche figée. Il ne faut donc pas espérer acheter un outil et se dire ensuite, « ça y est, on est DevOps ».
À noter qu’un outil DevOps doit lui aussi suivre une démarche DevOps. L’outil acheté aujourd’hui doit être en mesure d’évoluer pour répondre aux besoins de demain (et il faut effectuer les mises à jour). Si votre outil est figé, cela en est fini de votre démarche DevOps. Cela est valable si vous souscrivez à une offre de type SAAS ou IAAS hébergé en cloud ou on prem.
Le DevOps
Certaines entreprises considèrent que le DevOps est un poste (une fonction). Avoir une personne DevOps, c’est faire porter la responsabilité du process par une personne.
Comment faire en sorte que toute votre entreprise passe au DevOps, si la démarche DevOps n’est le sujet que d’une personne ? Comment faire si personne d’autre ne se sent responsable du fait que la démarche fonctionne ou échoue ?
C’est un peu comme passer à l’agilité en disant simplement : « Les chefs de projets sont maintenant des Scrum Master ». J’ai déjà vu ce cas. Cela ne change rien. Ce qui ne marchait pas avant ne marchera pas après. Et ce n’est pas la faute de l’agilité.
Le DevOps est une démarche qui est du ressort de tous. À la base l’objectif était de supprimer les différents sas étanches (ou mures de la confusion) qui compartimentent les équipes et nuisent à leur communication.
Si l’on centralise tout, de nombreuses questions se posent :
- Dans quelle équipe va aller votre DevOps ? Ou, de quelle équipe est-il originaire ? Dev ou Ops ?
- La communication dans tout cela ? Sera-telle aussi le sujet d’une seule personne ?
- Qui pilote le monitoring et choisit les métriques ?
- Qui s’intéresse à la qualité du code ?
- Qui s’intéresse au ressenti des utilisateurs ?
- Qui vérifie que l’infrastructure est en adéquation avec le besoin (quelles soit cloud, on prem, ou hybride) ?
- Qui vérifie que les outils DevOps sont en adéquation avec les besoins de chacun ?
- Que fait-on quand le DevOps n’est pas là ? Aurait-on créé un nouveau goulot d’étranglement ?
- Quid de la confidentialité ? On donne tous les mots de passe au Devops ?
Tant de questions qui ne pourront trouver réponse si une seule personne travail le sujet. Il y aura même des questions que le DevOps ne se posera pas, car elles ne font pas partie de sa sensibilité professionnelle (Dev ou Ops) ou de ses préoccupations du moment. Pour qu’une démarche DevOps fonctionne, il faut que tout le monde échange ouvertement sur ses préoccupations.
Sans cela, on finira sur la bonne vieille question : « on met en production ? »
Vous avez un Devops, mais vous êtes dans une situation sans démarche DevOps.
Si vous occupez un poste dit « DevOps », il faut travailler comme un facilitateur de la démarche DevOps et ouvrir les vannes. Si vous faites de la rétention, c’est mort. Il faut s’ouvrir aux autres et leur faire adopter la démarche tout en leur faisant comprendre que vous êtes soucieux de leurs besoins (Dev, Ops et utilisateurs). Il faut arriver à leur faire oublier votre titre de DevOps et surtout ne pas prendre parti pour une équipe.
Pour conclure
Je sais d’avance que certains souriront en lisant cet article. C’est une bonne chose. C’est que vous avez compris. J’espère avoir mis en évidence quelques points sur lesquels il faut rester vigilant.
S’il ne faut retenir qu’une phrase sur le DevOps, j’utiliserai celle que je martèle depuis des années :
« Le DevOps est de la responsabilité de tous »
Ou sa variante :
« Le DevOps est le souci de tous »