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

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.

Si vous utilisez un cluster Kubernetes installé sur OpenSuse, il est possible que celui-ci ait des petits loupés :

• Impossible de démarrer certains pods.
• La liste des évènements contient un message "CreateContainerConfigError: failed to prepare subPath for volumeMount"

Ce problème est provoqué par une régression dans util-linux en version 2.41.

Toutes les versions openSUSE ne sont pas concernées. Ce sont principalement les versions MicroOs, et Tumbleweed qui rencontrent ce problème, car elles obtiennent plus rapidement les nouveaux paquets que les autres. Il n'est pas impossible que d'autres distributions rencontrent le problème dans les prochains jours.

Pour savoir si vous êtes concernée, il suffit de lancer la commande :

rpm -q util-linux

Si elle retourne util-linux-2.41-1.1.x86_64, vous êtes concernés.

Si elle retourne util-linux-2.40.4-4.2.x86_64, ou une version précédente, tout va bien.

Concernant openSUSE, l'incident a été rapporté ici : 1244251 – util-linux 2.41 regression with kubernetes. Un correctif devrait être proposé rapidement.

Pour les utilisateurs de MicroOs, la solution la plus simple en attendant le correctif consiste à faire un rollback :

transactional-update rollback

Si celui-ci retourne un message d'erreur indiquant ERROR: `snapper rollback X` returned with error code 1., il suffit de demander un rollback sur la version X-1.

Exemple : pour l'erreur ERROR: `snapper rollback 33` returned with error code 1., il faut lancer la commande :

transactional-update rollback 32

Ensuite, il faut penser à relancer la commande rpm -q util-linux pour s'assurer de la version util-linux installée.

Derrière ce titre alarmant se cache en fait un mail envoyé aux utilisateurs de services Azure dépendants de .net 9.

Pour les personnes qui n'auraient pas reçu ce mail, voici un lien vers une conversation Reddit : Is .NET 10 finally out? : r/dotnet. Cette conversation reprend le mail dans son intégralité.

Ce mail est malheureux à deux niveaux :

• .net 10, n'est toujours pas en RTM. Passer un projet en production avec .net 10 avant novembre 2025 serait de la pure folie.
• Tout le monde n'a pas reçu ce mail. Ce qui crée un petit jeu du téléphone arabe. Il en résulte quelques frayeurs, et beaucoup d'interrogations.

Conclusion

• Non, il ne faut pas migrer de suite à .net 10.
• Oui, .net 9 est toujours supporté (correctifs jusqu'à novembre 2025, patch de sécurité jusqu'à mai 2026)
• Oui, Microsoft est peut-être allée un peu vite dans sa communication. Il y a peut-être un juste milieu à trouver entre le fait de prévenir les utilisateurs un an avant l'échéance, et prévenir à deux ou trois mois de celle-ci comme on peut le voir chez certains concurrents (non je ne vise pas G…..). Surtout que la durée du support de .net est connue des années en avance, contrairement à d'autres (non, je ne vis toujours pas G…..).

Voici la remédiation à un problème que j'ai récemment constaté sur un serveur hébergeant Azure DevOps.

Le disque système n'avait plus le poindre espace libre.

Après un petit diagnostique, j'ai constaté que le dossier "C:\inetpub\logs\LogFiles" contenait de gigaoctets de logs. S'agissant d'un dossier de IIS, la solution consistait donc, à reconfigurer lIS afin qu'il gère différemment ses logs.

Cela se fait en ouvrant la console IIS, en sélectionnant le site Azure DevOps, puis "Journalisation". Ici, il est possible de modifier la manière dont IIS gère les logs (planifications, tailles de fichiers, etc. ). Personnellement, je déteste explorer les logs pour identifier un problème, je préfère utiliser l'observateur d'évènements.

J'ai donc choisi de désactiver les logs au format fichier.

Ce qui donne la configuration suivante :

Depuis TFS 2008, c'est bien la première fois que je vois IIS configuré de la sorte. Je présume qu'il s'agit donc d'un cas isolé. Mais au cas où je préférais partager la remédiation ici.