La dette technique est un sujet difficile à traiter. Nombre d’éléments peuvent compliquer les choses :

• Technologies.
• Dépendances.
• Domaines fonctionnels traités.
• Criticité de l’application pour les utilisateurs.
• Coût.
• Temps.
• …

Il peut y avoir aussi quelques soucis d’ordre "culturel" (autre manière de ne pas dire "politique") :

• Désintérêt pour les aspects techniques.
• Manque de motivation.
• Peur des régressions.
• …

Même si ce n’est pas facile, tout le monde peut surmonter ces problèmes, et résorber sa dette technique. Cela ne se fera peut-être pas rapidement. Il est préférable de l’accepter. Le jeu en vaut la chandelle.

Mais il est des situations qui peuvent compliquer les choses de manière irrémédiable. Je me propose de vous présenter ici trois cas réels, et vécus en ESN (à l’époque, on disait SSII, mais je m’adapte). Soyons claires tout de suite. Aucune des situations présentées ici n’est liée à mon emploi actuel, et j’en suis fort heureux. Travaillant aujourd’hui pour un éditeur, je crois que j’aurai beaucoup de mal à les vivre à nouveau. Contrairement aux éditeurs, les ESN ne sont souvent que "de passage" sur une application. Les développeurs / consultants qui assurent une mission à un instant T vivent donc "différemment" la dette technique. Personnellement, je n’ai jamais bien vécu cette expérience, et encore moins le fait que l’on me demande de la faire passe sous le tapis. C’est tabou. Il ne faut pas en parler au risque de déplaire au client. Bêtement, j’ai toujours pensé que le client adorerait qu’on lui remette un rapport sur celle-ci. Une ESN plus futée se rendrait peut-être compte que le sujet peut apporter d’autres prestations.

Cela fait maintenant quelques années que je ne travaille plus dans le domaine du conseil. Je vais pouvoir commencer à me lâcher un peu, sans qu’un client ait l’impression d’être l’objet d’un article.

Pas de panique, il ne s’agit pas d’un changement de ligne directrice de ce blog. Je reste sur les lignes originelles de ce blog : du .net, de la Tech, un côté geek assumé, et toujours une petite dose d’humour. Je vais juste m’autoriser à discuter de sujets plus "sensibles".

Je débute donc une nouvelle série d’articles sur quelques "tabous" des métiers de l’IT, du Dev, et des ESN.

Au plaisir de lire vos commentaires, et mails sur ces sujets ;)

Effectuer la mise à jour d'une ferme Azure DevOps peut prendre un peu de temps. Cela dépend de l'infrastructure, du nombre de collections à migrer, de la taille de celles-ci, et aussi du support utilisé pour la migration.

Depuis quelques années, Microsoft a mis à disposition des exécutables pour installer Azure DevOps (exécutables de type Web Installer, comme pour Visual Studio Installer). Ceux-ci sont un peu trop mis en avant à mon goût.

Jusqu'ici, identifier la version d'Azure DevOps Server installée n'était pas facile. On pouvait obtenir un numéro de version majeur, et c'était tout. Sachant qu'il n'existe aucune documentation résumant les numéros de version, l'intérêt est limité.

Encore aujourd'hui, si on ouvre une console d'administration d'Azure DevOps Server, on obtient une information limitée.

Sur le détail de la couche applicative configurée, l'information est similaire :

Ceci n'est pas très parlant.

Heureusement, il existe une page "À propos" sur le portail web. Celle-ci est disponible via le lien suivant : https://mon-nom-dns/tfs/ma-collection/_home/about . Depuis Azure DevOps Server 2022, on peut y lire la date du patch appliqué et sa version. Enfin une information facilement exploitable!

Ma capture d'écran date un peu. En l'occurrence, il s'agit du premier patch publié après la sortie de DevOps Server 2022 en décembre 2022.

Pour rappel, avant Azure DevOps Server 2022, la page ressemblait à ceci:

Après quelques mois de test, et 4 Release Candidates, WIX Toolset sort enfin en version 4.0.0. Le projet a pris un peu de retard. Mais c’était pour la bonne cause. Cette version 4.0.0 était très attendue. Il était donc hors de question que sa sortie soit entachée par des bugs.

Pour rappel, la version 4 apporte des modifications majeures suivantes :

• Les projets WIX utilisent le nouveau format de projet de type SDK de .net core.
• Le toolkit s’installe via nuget.
• Le toolkit ne dépend plus du .net Framework 3.5.

Inutile de vous faire un dessin de la totalité des nouveautés. Si vous avez déjà utilisé WIX 3, les avantages sautent aux yeux :

• Les actions post-build sont beaucoup plus faciles à configurer.
• L’automatisation des builds, et la gestion des serveurs de build sont beaucoup plus faciles.

Ce toolkit n’aura jamais été aussi facile à mettre en œuvre pour générer des fichiers MSI.