La culture DevOps est-elle vouée à disparaitre ?
DevOps, DevOps, DevOps… On veut du DevOps ! DevOps est là, DevOps est partout et à toutes les sauces. Tout le monde ou presque parle de DevOps, se revendique DevOps. DevOps est devenu tendance et pour être tendance, il faut associer son nom ou sa marque à DevOps.
Mais quel est vraiment ce DevOps dont tout le monde parle ?
DevOps est une culture, une manière de travailler de concert pour d’atteindre des objectifs communs. Ce n’est pas le fait d’une seule personne dans l’entreprise ni une somme de compétences techniques portée par un seul groupe.
Aujourd’hui quand j’échange avec d’autres personnes, et entreprise ou quand et je lis des sujets sur DevOps, je vois les « murs de la confusion » se dresser.
Concrètement, cela pourrait ressembler à cela :
On dresse des barrières entre les équipes, les personnes et/ou les responsabilités. On a juste ajouté la notion de DevOps comme on ajouterait un nouvel antagoniste. Si votre entreprise avait déjà une certaine résistance au changement. Les choses ne vont pas s’arranger. La culture DevOps ne prendra pas.
Ce n’est pas DevOps. DevOps est justement là pour faire tomber ces barrières. Aboutir à une transformation numérique réussie.
DevOps dans la culture marketing / communication / ESN
Il ne faut pas se mentir, DevOps est un buzzword. Certains diraient un mot « p… à clic » (oui je censure quelques termes dits « marketing »).
Dans ce contexte, ce mot est uniquement là pour attirer le visiteur. Parfois, on arrive sur des sites qui parlent uniquement d’infrastructure, ou de développement.
J’ai déjà rencontré le cas d’un article étiqueté DevOps qui vantait les mérites du cycle en V. Il décrivait entre autres, la notion de fin de projet bornée à la livraison de l’application au client. Rien à voir avec la culture DevOps.
DevOps perd alors rapidement son sens. Je fais souvent le parallèle avec le Web 2.0. Personne ne savait vraiment de quoi il parlait, mais tout nouveau site Web était 2.0. Il fallait vendre des nouveaux sites étiquetés Web 2.0.
En écrivant cela, je pense aussi à l’Agilité. Beaucoup de sociétés de service ont compris l’intérêt marketing de l’Agilité. Elles n’en ont pas pour autant saisi le sens ni la culture de transparence et de communication qui lui sont associées. C’est ce qui fait qu’aujourd’hui l’Agilité est très critiquée. Elle a servi de bouc émissaire pour expliquer l’échec de nombreux projets.
Je m’inquiète pour la culture DevOps, car ce sont très souvent ceux qui critiquent aujourd’hui l’Agilité qui prônent le DevOps. Ont-ils compris qu’il y avait un lien entre Agilité et DevOps ?
DevOps et outils
Les outils jouent un rôle important dans l’adoption de DevOps. Mais ce n’est pas tout. Je ne vais pas faire un article complet sur le sujet, je l’ai déjà traité ici.
Aujourd’hui, il y a pléthore d’outils. Mais tous ne portent pas la culture DevOps à tous les utilisateurs.
Pennons deux outils pour exemples : Jenkins et Azure DevOps.
Plaçons-nous dans un contexte où l’on veut faire adhérer des utilisateurs réfractaires à l’informatique à notre processus de livraison (le fameux Continuous Delivery caché derrière les lettres CD).
Ces utilisateurs vont avoir la responsabilité de tester les applications et de valider les mises en production.
Deux scénarios sont possibles :
- SI j’ai la culture de l’outil, et non du DevOps, je vais imposer mon outil.
- Si j’ai la culture DevOps, je vais choisir un outil adapté ou adapter mon outil.
Dans le cas de Jenkins : Je ne peux pas imaginer fournir celui-ci à des utilisateurs réfractaires à l’informatique. Même si j’aime bien l’outil, c’est la mort assurée du projet. Il faudra l’associé à d’autres outils qui feront office de frontal pour ces utilisateurs et d’outils de remontée de tests. Les équipes des développeurs et de l’IT doivent réfléchirent à une solution adaptée et ne pas se borner aux outils connus. Ils ne doivent pas se borner à penser CD, ils doivent aussi penser tests fonctionnels et expérience utilisateur.
Dans le cas de Azure DevOps : L’outil dispose déjà d’un workflow d’approbation trivial et d’outils de tests orientés utilisateurs fonctionnels. Il faut donc veiller à former les utilisateurs.
Oui, dans une culture DevOps on forme et on informe les utilisateurs, même si l’outil semble trivial. Cela permet d’avoir leurs retours et de mieux comprendre leurs attentes. C’est en faisant cela que l’on met en place une culture DevOps.
Conclusion
Derrière DevOps, il y a une culture orientée vers :
- L’aboutissement des projets.
- La transparence.
- La communication.
- Le maintien en bon état de fonctionnement.
- L’adéquation des projets avec les besoins (Utilisateurs, Développeurs, IT Pro … VIP).
Si l’on perd cette culture, DevOps est fini.