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.

En temps normal, un fichier de configuration pour Linux doit se trouver dans un dossier /etc/monapplication. Ce que peu de développeurs .net font. Si vous souhaitez respecter les habitudes de vos gentils administrateurs système, il faut utiliser ce dossier.

Avec Windows, le fichier de configuration se trouve généralement à la racine de l'application.

Concilier les deux est possible et ne demande aucun effort. Nul besoin de s'arracher les cheveux ni d'ajouter un code détectant l'OS. Il suffit de profiter des possibilités offertes par le ConfigurationBuilder, et la méthode AddJsonFile :

• On effectue un appel de AddJsonFile pour chaque chemin possible.
• On indique que chaque fichier de configuration est optionnel.

Voici un exemple d'application Console :

using Microsoft.Extensions.Configuration;

namespace ConsoleApp1
{
  internal class Program
  {
    static void Main(string[] args)
    {
      var configuration = new ConfigurationBuilder()
        .AddJsonFile("appsettings.json", true)
        .AddJsonFile("/etc/monapplication/appsettings.json", true)
        .Build();
 
        var message = configuration.GetValue<String>("message");
 
        Console.WriteLine(message);
      }
  }
}

Avec le fichier de configuration appsettings.json:

{
  "message": "Coucou"
}

Au final :

• S’il y a un fichier de configuration dans "/etc/monapplication", celui-ci sera utilisé (même s’il y en a un à la racine de l'application). Les dernières informations trouvées remplaçant les informations trouvées précédemment.
• Sur Windows, le fichier de configuration utilisé sera celui qui se trouve à la racine de l'application.

Ce code est exploitable dès qu'une application utilise l'hôte générique destiné à l'injection de dépendances.

Suite à l’un de mes articles sur Azure DevOps Server, il m’a été demandé de faire le point sur les notions d’Update et de Patch. Si vous gérez ou souhaitez héberger votre propre ferme Azure DevOps, il est effectivement impératif de comprendre ces deux notions, et leur impact sur votre plateforme.

Pour être clair sur ce sujet, il faut comprendre ce dont on parle et fixer trois notions :

• - Version majeure : 2019, 2020, ou 2019
• - Update : 2020 Update 1.1, 2002 Update 1.2, ou 2029 Update 1.2
• - Patch : 2022 Patch 1, 2022 Patch 2, ou 2020 Update 1.2 Patch 5.

Note : j’ai volontairement retiré le préfix Azure DevOps Server, afin d’être moins "verbeux".

Les différentes évolutions d’Azure Pipeline ont amené beaucoup de bonnes choses. Dont une belle simplification de la gestion des stratégies de rétention des builds. Mais ceci est arrivé avec un petit effet de bord : des pipelines qui ne disposaient pas d’une stratégie de rétention voient leurs exécutions affublées d’un bail "Legacy Retention Model".

La problématique

Le bail "Legacy Retention Model" interdit la suppression des exécutions.

Aucune stratégie n’étant définie avant l’évolution de cette fonctionnalité, Microsoft ne peut pas prendre la décision de supprimer des exécutions à notre place. La démarche est donc logique.

Pour pourvoir supprimer les excitions concernées, il faut donc retirer les baux. Cette opération peut être fastidieuse si vos avez beaucoup de pipelines, projets, ou organisation / collections.