Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

La bonne pratique voudrait que tout code .net soit CLS Compliant. Aujourd'hui, on peut se demander pourquoi faire la remarque. Mais, je me suis rendu compte que nombre de développeurs ne savent pas ce que cela signifiait.

En une phrase : Un code CLS Compliant peut être appelé par un projet C#, F#, ou VB sans problèmes.

Quand le compilateur dit qu'un code n'est pas CLS Compliant, c'est donc qu'il y a un risque que votre librairie ne soit pas exploitable dans un autre projet. Attention : un autre projet peut utiliser votre code et compiler sans problèmes. Mais à l'exécution il peut y avoir des effets de bord.

Ex: une classe écrite en C# avec deux méthodes ayant le même nom, les mêmes arguments. Mais sur l'une d'elle, l'un des arguments est préfixé d'un "ref". VB ne sera pas en mesure de faire la différence entre ces deux méthodes.

Comme l'explique très bien la documentation, il y a beaucoup d'autres cas. Je présente celui-ci, car comme beaucoup de problèmes de codes non CLS Compliant, il y a là un problème de qualité de code. Cette manière de coder complexifie la lecture du code, et vos collègues, ou utilisateurs de votre librairie ne comprendront peut-être pas bien vos intentions.

Si vous n'utilisez un seul langage, un warning de type "not CLS Compliant" est à prendre comme un problème de qualité à traiter.

Il y aura malheureusement des cas où l'on doit utiliser des librairies, et des classes non CLS Compliant. Je pense par exemple à l'usage de très anciens interops Office.

Dans ces cas, là il y a une approche très simple à suivre :

• Ne pas utiliser ces types comme arguments de vos méthodes publiques.
• Créer des classes "passe-plat" qui seront CLS Compliant, et qui porteront les propriétés dont vous avez besoin pour créer en interne l'objet non CLS Compliant.

Si cela n'est pas possible, il faut marquer la classe avec l'attribut suivant (ceci est le dernier recours, on est d'accord?):

[CLSCompliant(false)]

Mais surtout, il ne faut pas utiliser cet attribut au niveau de l'assembly. Si vous l'avez dans votre projet, passez-le temporairement à true pour observer les dégâts, et planifier leur remédiation.

[assembly: CLSCompliant(true)]

Cet attribut mis à false, est là pour cacher la misère. Il finira toujours par propager les problèmes.

J’ai choisi de vous partager aujourd’hui une déconvenue qui m’a fait réfléchir. Lors d’une présentation d’Azure DevOps Server (usages pro, et possibilités), il m’a été reproché de promouvoir / défendre le produit.

J’ai été décontenancé par la remarque, et me suis rendu compte que ma présentation pouvait effectivement être prise comme telle.

À être trop enthousiaste vis-à-vis d’un outil peut donner une mauvaise idée de nos intentions. Quand on aime le DevOps, créer de la confusion, ce n’est pas « foufou » (oui, je le permets une expression de vieux). « Sacrebleu », briser le mur la confusion, c’est DevOps !!!

Moralité

Attention à sa posture quand on parle d’outils que l’on aime utiliser.

Conclusion ++

Jusqu’ici, je gardais toujours ma liste avantages / inconvénients pour déclencher la conversation off qu’il y a toujours en fin de réunion. Maintenant je ferai une slide à l’ancienne avec le menu, et un gros titre « inconvénients ».

Et vous

Ce genre de méprise vous est-il déjà arrivé ?

PS : Oui je vais rédiger un article au sujet de ce qui est pour moi LE très gros inconvénient d’Azure DevOps Server.

J'ai le plaisir de vous annoncer que Microsoft m'a décerné un nouveau MVP Award. Cette année dans la catégorie DevOps. Ce qui m'emplit encore davantage de fierté.

Après avoir été reconnu durant 15 ans pour mes travaux sur .net, et ses outils, être récompensé pour un autre aspect du métier est très agréable.

Merci à Microsoft pour cette reconnaissance, et merci à tous ceux qui prennent le temps de me lire.

Un remerciement tout particulier pour celles, et ceux qui prennent le temps de m'envoyer un petit message pour le soutenir, ou entamer la discussion sur .net et DevOps. Mes derniers articles m'ont permis d'avoir de nombreux retours. J'en suis très heureux. Je vais donc continuer sur cette lancée ;)

Suite à mon précédent article, il m’a été demandé si j’allais me mettre à critiquer les méthodes agiles. Désolé, il n’en est rien. Je ne renierai, et ne critiquerai pas les méthodes agiles.

Ma raison est très simple :

J’ai eu la chance de faire de l’agilité sans le savoir, à une époque ou personne ne parlait d’agilité en France. Par la suite, un collègue m’a fait découvrir l’Extreme Programming (XP). Ce fut une vraie révélation. Depuis, l’amélioration continue est devenue ma façon de vivre le développement logiciel.

Donc non, je ne peux pas critiquer l’agilité. Je reconnais qu’il y a une véritable mode à ce sujet depuis quelques années. Une sorte de tendance à suivre... (ou pas).

Pourquoi ?

Si vous êtes attentifs, vous vous rendrez compte que nombre de détracteurs de l’agilité vantent les métrites du DevOps, ou du DevSecOps, tout en reniant Scrum, et/ou le manifeste agile.

Vous vous dites peut-être que je tends à faire une grosse généralité, et que je mélange tout. Très bien, vous êtes attentifs, et comprenez le sujet. C’est exactement là que je souhaite vous mener.

Au sujet du manifeste agile :

j'avoue que je ne suis pas fan. À mon sens, ce n'est pas utile. Il s'agit d'une déclaration d'intention à laquelle tout le monde ne doit pas être tenu. Chaque équipe doit être libre, et doit faire évoluer sa méthode en fonction de ses propres objectifs, et de sa maturité.

L’agilité : « comptable désignée » ?

Avec le temps, l’agilité est devenue un gros four tout purement commercial pour certains. Cela va de l’ESN, aux coachs agiles, en passant par les AMOE, AMOA, et chefs de projets convertis à la hâte en Scrum Masters.

Oui, je mets les coachs agiles dans ce panier de crabes. Tous ne sont pas concernés pour autant. Je désigne ici le coach qui travaille 100% de son temps pour une même équipe depuis des années… Pourquoi cette équipe ne vole-t-elle toujours pas de ses propres ailes ?

L’agilité a été un beau business. Mais certains clients se sont rendu compte que les promesses n’étaient pas au rendez-vous.

Par chance, DevOps est arrivé (« sans se presser, le grand Zorro… »).

Il fallait donc changer de méthode, et blâmer l’agilité. Sans pour autant se rendre compte que l’agilité était une composante de DevOps. Mais ceci est un autre sujet.

Conclusion

Je pense donc que le problème est lié aux personnes qui ont fait de l’agilité leur business, mais qui n’ont pas su adhérer aux méthodes.

Et la suite ?

Peut-être, pensez-vous que DevSecOps est arrivé et qu’il faut chasser DevOps. Désolé, je ne critiquerai pas DevOps au profit de DevSecOps. J’ai toujours considéré que la sécurisation de la chaine de production, et livraison faisait partie du package. Pour moi, DevSecOps est un nouveau terme marketing. Mais s’il peut faire comprendre que la sécurité doit être incluse by design dans le DevOps, je ne peux pas non plus le critiquer.

Comme l’agilité, DevOps n’est pas figé, et s’inscrit dans une logique d’amélioration continue.

Exemple :

La disparition progressive des Personnel Access Token dans Azure DevOps, n’est pas « une nouveauté DevSecOps ». C’est une évolution qui s’inscrit parfaitement dans la logique Zero Trust que nous devrions tous adopter. En 2025, combien de ces tokens finissent encore dans des repos Git ?

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.