Pourquoi tous les outils DevOps ne se valent-ils pas ?
Attention âmes sensibles, voici un article écrit à cœur ouvert, et sans langue de bois.
Suite à une énième publicité pour l’outil "X" qui fait du DevOps mieux que les autres, et qui va révolutionner votre manière de travailler, je craque !
Important : La lettre "X" est utilisée ici pour désigner un produit lambda. Il ne s’agit donc pas de discuter de réseaux sociaux, ou de contenu pour adultes.
Mais revenons à nos moutons. Les outils DevOps se ressemblent peut-être, mais ils ne se valent pas tous. Comme à mon habitude, je vais débuter par la conclusion :
Toutes les équipes, développeur, et IT Pro, sont différentes, et utilisent des méthodes différentes. Penser qu’un outil est forcément bon pour tout le monde est donc une gageure. Ou alors, on nous mentirait depuis le début et nous ne serons que des clones…
DevOps ?
Première aberration parmi tant d’autres. Tout le monde ou presque va être d’accord pour énoncer le fait que DevOps existe pour briser la barrière entre Dev, et Ops (ou retire le “mur de la confusion”). Cependant le choix de l’outil est souvent fait par les développeurs sans concertation avec les opérations.
Pire, chacun a son outil, car chacun dépend d’une direction différente.
… et on parle encore de DevOps.
Comment voulez-vous qu’un outil DevOps arrive se fondre dans ce moule ?
Pire : parfois les échanges entre équipes ne passent que par du ticketing. Pour la traçabilité, cela se comprend. Mais qui est à l’origine du workflow ? Qui à la visibilité sur celui-ci ? Là encore, tous les produits n’arrivent pas à entrer dans tous les moules, et tous n’offrent pas la visibilité nécessaire pour les différents intervenants. Sans parler de délégation, et de gestion des droits (qui peuvent parfois être décuplés par la multiplication des outils interfacés les uns aux autres).
Gestion de projets ?
En 25 ans de suivi de projets, je ne crois pas avoir vu deux équipent utiliser exactement les mêmes méthodes de suivis de projet. Azure DevOps, Wrike, Jira, Mentis, GLPI, GitHub, GitLab… chacun a sa base. Mais personne ne l’utilise vraiment de la même manière, ni avec les mêmes objectifs.
Oui, dans cette liste, il y a des outils qui ne font que du ticketing. Cela colle malheureusement à la réalité de ce monde. Nombre d’entreprises font de l’agilité, et/ou du DevOps en pensant uniquement ticket / issue (et pense être agile, ou DevOps). Mais ce n’est pas l’objet de cet article.
J’ai passé le plus clair de mon temps avec TFS / Azure DevOps. Je l’apprécie justement pour cette capacité à porter la gestion de projets, la communication, et avec en prime au beau plan de livraison pour partager la roadmap et les jalons. Ce que très peu d’outils intègrent.
Gestion de repository ?
Mono repository sur Git, et on est tous content ! Pas besoin d’autres choses.
Soyons là encore honnêtes. Certains projets peuvent avoir besoin de plusieurs repos. C’est le cas par exemple de l’un des projets sur lequel je travaille. Il y a un repo avec le produit principal, un second avec un produit qui se rapproche d’un fork allégé du premier, et deux repos dédiés à des tests d’intégrations, et de non-régression des interfaces. Le tout avec un suivi de projet commun, et des builds pouvant s'enchainer (plus triggers planifiés).
D’autres projets dépendent de formats qui ne sont pas "git friendly" (gros binaires, format propriétaires) qu’il faut pourtant versionner. Pour ces cas-là, il faut autre chose.
Attention : Git LFS ne fait pas tout. C’est une grave erreur de croire que cela suffit à répondre à toutes les problématiques.
Autre petit sujet lié au repository : Tout le monde n’a pas besoin de pull-request, ou de stratégie de branches complexe. Mais si tel est le cas, ces éléments doivent être facilement compréhensibles par tous. Il n’y a rien de pire que de ne pas savoir pourquoi une fusion est impossible.
Gestion de l’intégration, et de la livraison en continu ?
À ce sujet, je serai tenté de dire que tout est dans le titre que j’ai choisi pour cette section. Volontairement, je ne parle pas de CI/CD, car nombre de produit ne font pas la distinction entre Delivry, et Deployment.
Si on veut faire du DevOps, il faut faire la distinction entre les deux. Si votre outil se borne au déploiement, vous aurez peut-être quelques difficultés. Il faudra alors ruser pour interfacer votre outil sur un autre (un niveau de complexité en plus, un !).
A contrario, vous pourriez tomber sur un outil qui est fait trop (et qui fournit trop d’options différentes pour faire la même chose). Ce qui peut introduire un risque de faire les mauvais choix à long terme.
Ex : Outils qui n’ont pas de tâches « adaptées » pour la CLI dotnet, msbuild, ou vstest. Tâches pour lesquelles il faut donner un chemin vers les exécutables à utiliser. L’enfer le jour où l’on veut utiliser les nouveaux outils, et qu’il faut modifier la totalité des définitions de builds dans la totalité des branches supportées.
Attention aussi aux outils d’analyse de code "trop génériques". S’ils sont un très bel argument pour choisir une solution DevOps, il faut faire attention à ce qu’ils ne vous vendent pas trop de rêves.
J’ai encore en tête les heures passées à argumenter sur un ticket demandant de corriger une méthode. Cette méthode devait renvoyer un objet. L’outil de qualité de code demandait d’effectuer un Dispose de l’objet avant de le renvoyer à l’appelant ….
Que de temps perdus du fait d’un outil non adapté (attention on parle là de l’un des leaders du marché)
Gestion des dépendances ?
Avec le DevSecOps, nombre d’outils permettent maintenant de vérifier si nos projets utilisent de librairies reconnues comme contenant des failles. Ceci est très pratique, mais parfois limité quand un projet mêle plusieurs technologies, ou des solutions recompilées (ex : .jar coté serveur, et bundle js compilé côté client,sans conserver de packages.json pour node.js).
Problèmes, ces outils intégrés à notre plateforme DevOps peuvent être supplantés par les outils de Dev. Exemple : nuget fournit des avertissements à l’installation, et la restauration. Ces mêmes avertissements peuvent remonter dans les pipelines de builds, et bloqué celles-ci si besoin.
L’argument DevSecOps de certains outils prend un peu de plomb dans l’aile.
Autre petit problème : analyser les dépendances, c’est bien. Sécurisé leur accès ou le stockage de dépendances maison, c’est mieux. Là encore, tous les outils ne se valent pas (type de dépendances limitées, coût du stockage, ou incapacité de ne pas payer pour le stockages de dépendances des upstreams). À quoi bon faire de beaux packages nuget ou maven si on ne dispose pas d’un outil DevOps à la hauteur ?
Gestion des tests ?
Tester, tester, et encore tester ! Cela semble normal quand on parle DevOps. Mais de quel genre de tests parle vraiment votre outil DevOps ? Tests unitaires ? Tests d’UI automatisés ? Tests fonctionnels avec cahiers de recettes ? Tests de montée en charge ?
Là encore, il n’y a pas des massent d’outils qui intègrent toutes les familles de tests, et qui prennent en compte la notion de testeur fonctionnel et/ou technique.
Si seulement je pouvais gagner quelques euros pour chaque équipe que j’ai vu utiliser Excel pour formaliser, et suivre des cahiers de recette.
Gestion du monitoring ?
Là encore, chaque application que vous développez a ses propres besoins. Forcer le monitoring en fonction d’un outil DevOps, ou d’une stack Dev me stupéfait. Pourtant, il y a des sociétés qui voudront à tout prix vous rendre leur système de sonde, ou de librairie tout intégrée.
En 2025 : Open telemetry associé à une stack stockage + reporting,+ alerte, adaptée, feront parfaitement l’affaire sans vous limiter (chaque brique pourra même être replacée à l’avenir).
Conclusion
Je ne change pas d’avis. Nous ne sommes pas des clones. Méfiez vous des publicité DevOps trop alléchantes. Chacun a son, ou ses outils DevOps, et ses usages. Si par chance, vous avez un outil qui vous comble, et qui sait évoluer avec vous, c’est gagné.
…
Cela me donne très envie de rédiger un article sur la manière de rater à coup sûr l’Agilité, le DevOps, ou le DevSecOps.