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

Je constate avec beaucoup de plaisir qu’il y a un très fort engouement de la communauté .net autour du format de solution SLNX. Je ne reviendrai pas sur l’intérêt de ce nouveau format. Je crois que tout a déjà été dit sur le sujet. Il est évident que le SLNX va très vite s’imposer.

Cependant, il ne faudrait pas mettre la charrue avant les bœufs :

• Oui, sur le plan technique, on peut tous adopter ce nouveau format.
• Non, sur le plan pratique, tout le monde ne peut pas l’adopter de suite.

Vous allez me dire : “ C’est du Jérémy tout craché. Il ne peut pas dire oui sans dire non “. Vous n’aurez pas totalement tort. Dans le cas présent, ma réserve s’appuie sur les bases suivantes :

• Le tooling utilisé par les développeurs doit être compatible.
• Le tooling utilisé pour les builds doit être compatible.

Ces deux conditions doivent être remplies, et les outils doivent être déployés avant de commencer la migration. Faute de quoi, il y aura des problèmes.

Attention : ce n’est pas parce qu’un outil est compatible que l’opération se fera toute seule. Exemple : Visual Studio 17.13 supporte les SLNX, à condition d’activer la fonctionnalité via le menu des options (fonctionnalité qui est stable, mais toujours cataloguée en « preview » ).

De plus, si vous avez à maintenir plusieurs versions majeures de vos applications, il faudra fusionner très vite les branches relatives à la migration pour éviter d’autres problèmes.

Depuis quelque temps déjà, il est possible d’utiliser Windows Update pour maintenir Visual Studio à jour.

Mais est-ce une bonne idée ?

Très honnêtement, cela dépend. J’ai bien conscience que personne n’apprécie ce genre de réponse. Mais il faut être factuel. Tout dépend de la manière utilisée pour administrer les PC des développeurs.

Par défaut

Si cette fonctionnalité est activée et gérée par librement par le développeur, l’expérience est fluide :

• Les mises à jour sont téléchargées en tâche de fond.
• Les mises à jour ne sont pas installées durant les périodes d’activités (horaires configurables via Windows Update).
• Les mises à jour ne sont pas appliquées si Visual Studio est utilisé.

En somme tout va bien.

Configuration centralisée

Si la mise à jour est pilotée par vos administrateurs : « ça passe, ou ça casse ». Microsoft a offert tellement de possibilités pour piloter les mises à jour, qu’il est très facile de se tromper. Si vous avez l’intention de centraliser les mises à jour, je vous conseille vivement de mettre en place une approche similaire à ceci :

• Mettre en place un groupe de développeurs pilotes (avec qui échanger sur les besoins et usages de Visual Studio).
• Mettre en place une stratégie de déploiement progressive (avec des tests sur un nombre de PC restreints)
• Ne pas chercher à modifier trop d’options à la foi.
• Tester, tester, tester !

Le secret réside dans l’échange, et le test. Une mise en place trop brutale en ne considérant que l’aspect « applications des mises à jour de sécurité » est vouée à l’échec (indisponibilité de Visual Studio, outil inutilisable, impossibilité d’ajouter des fonctionnalités dépréciées, etc…).

Pour aller plus loin

Voici quelques liens très intéressants :

• Keep Visual Studio automatically updated and secure through Microsoft Update.
• Deploy Visual Studio updates to devices enrolled in Windows Update for Business.
• Enable Group Policy Settings with Visual Studio Administrative Templates (ADMX).
• Guide de l’administrateur Visual Studio

Certaines personnes semblent avoir été un peu surprises par l'arrivée de l'agent Azure pipeline en version 4. Même si une très grosse partie des informations concernant les évolutions de cet agent sont consulta via GitHub, la documentation reste sur Microsoft Learn.

On peut entre autres, y trouver une FAQ très complète de la version 4. Celle-ci est disponible via ce lien : Agent software version 4 - Azure Pipelines | Microsoft Learn

Actuellement, Azure DevOps Server est livré avec une version 3 de l'agent Azure Pipelines. Il est cependant tout à fait possible d'installer, et d'utiliser la version 4.

Celle-ci est parfaitement compatible avec Azure DevOps Server 2022 update 2.

Testé, et approuvé avec le patch 2 de novembre 2024.

En cas de besoin, voici un article expliquant la méthode permettant de forcer à la mise à jour des agents.

Si vous suivez le GitHub de l'agent Azure Pipelines vous avez peut-être constaté que la dernière release est taguée v4.251.

Le changement de numérotation peut surprendre, mais il s'explique par une évolution majeure. La version 4 utilise .net 8.

La première version 4 a été distribuée en octobre / novembre dernier. Cependant, elle n'a pas été taguée comme étant la dernière version stable. L'utilisation de .net 8 rend l'agent incompatible avec certains OS, car ils n'ont pas été mis à jour pour supporter .net 8 (distributions Linux principalement, plus quelques anciennes versions de Mac OS, et Windows dépréciés). Le détail est disponible ici.

La mise en avant de la version 4 fait donc suite à la fin du support de .net 6.

Microsoft ne force pas le passage à la version 4. Une version taguée v3.251 utilisant .net 6 reste disponible. Vous pouvez donc continuer à utiliser cet agent, si vos OS ne sont pas supportés.

Attention

Même si la version 3 reçoit des correctifs, elle ne pourra pas pallier un éventuel problème lié à .net 6. Il est donc fortement conseillé de passer à la version 4 dès que possible.