Introduction

Azure DevOps permet, par le biais des pipelines, de créer toutes formes d’artefacts destinés à être exploités ou distribués. Dans le chapitre Pipelines : automatisation, nous avons étudié les pipelines en générant et en déployant un site ASP.NET sur Azure.

Les applications web sont un type d’artefact que nous pouvons produire à la sortie d’un pipeline. Le développement applicatif est aujourd’hui plus modulaire que jamais. Les langages les plus répandus travaillent désormais tous avec un gestionnaire de package : NuGet pour .NET, NPM pour JavaScript, etc.

Azure DevOps offre une fonctionnalité permettant d’héberger un flux de packages directement au sein d’un projet, et ce pour les technologies les plus répandues. Avec cette approche, il est possible non seulement de publier, mais également de consommer les packages créés par l’entreprise en bénéficiant d’un flux privé.

Créer un flux

En cliquant sur l’élément de menu Artifacts dans le menu principal d’Azure DevOps, nous arrivons sur la page de gestion des flux présents dans notre projet. Par défaut, nous sommes sur le flux d’organisation créé lorsque nous avons créé notre organisation Azure DevOps.

Bien que nous accédions à cette page en venant d’un projet en particulier, un flux peut être déclaré pour toute une organisation, comme nous pouvons d’ailleurs le constater par le biais du menu déroulant présent en haut à gauche de la page :

Liste des flux

Pour créer un flux, il y a deux approches possibles :

Avoir un flux privé qui ne contient que les packages privés du projet ou de l’organisation, selon la portée.
Avoir un flux privé qui contient les packages privés, mais qui sert également de source proxy pour les packages publics.

La seconde approche est souvent utilisée pour maîtriser les mises à jour des packages publics. En effet, lorsqu’un développeur utilise un IDE permettant la mise à jour des packages (fonctionnalité présente dans la majorité des IDE en .NET), s’il est branché sur un flux public, il n’y a pas de maîtrise sur les versions des packages qui seront installés sur le projet....

Créer et publier un package

Pour nous assurer que notre flux est opérationnel, nous allons créer et publier notre premier package depuis notre poste de développement. La procédure est assez simple.

La première étape est de créer un nouveau projet de type librairie de classes sur notre poste, par le biais de la commande suivante :

dotnet new classlib -n MonPackage

Prenez garde à bien exécuter cette commande dans le répertoire de travail lié à Azure DevOps, à côté du dossier MonSiteASP, pour éviter de mélanger les différents projets.

Nous n’allons pas écrire de code particulier au sein de notre package, juste faire en sorte qu’il soit publié et puisse être récupéré.

Pour créer un package NuGet, il faut renseigner certaines informations dans les propriétés de la librairie de classes. Nous pouvons faire cela facilement par le biais de Visual Studio, en faisant un clic droit sur le projet, puis en choisissant Propriétés. Dans la fenêtre des propriétés, le menu Package nous permet de renseigner un grand nombre d’informations sur les métadonnées du package qui sera publié.

Dans le cas d’un package privé, certaines informations peuvent paraître inutiles, comme l’auteur ou la société. Il est toujours préférable de renseigner ces informations à des fins de cohésion, mais ce n’est en rien obligatoire. L’information de la version, quant à elle, est essentielle. En effet, un flux de packages NuGet est réputé pour son immuabilité. Cela signifie qu’une version d’un package déjà publié ne peut être supprimée (nous verrons qu’Azure DevOps autorise...

Consommer un package depuis le flux privé

Héberger nos packages sur un flux privé n’a en soi pas grand intérêt si nous ne les consommons pas. À cet effet, bien que ce package ne fasse rien de spécifique, nous allons ajouter une référence à ce package à notre site ASP.NET :

<Project Sdk="Microsoft.NET.Sdk.Web"> 
  <PropertyGroup> 
    ... 
  </PropertyGroup> 
  <ItemGroup> 
    <PackageReference Include="Microsoft.EntityFrameworkCore. 
SqlServer" Version="7.0.2" />  
    <PackageReference Include="MonPackage" Version="1.0.0" /> 
  </ItemGroup> 
</Project>

Cependant, si nous tentons la compilation à la suite de cet ajout, nous risquons d’avoir l’erreur suivante :

Error NU1101: Unable to find package MonPackage. No packages exist with this id in source(s): Microsoft Visual Studio Offline Packages, nuget.org

En effet, la recherche de packages s’effectue sur les sources configurées par défaut, notamment nuget.org, qui est le fournisseur officiel. Microsoft Visual Studio Offline Packages est utilisé en cas de compilation avec Visual Studio, ce dernier conservant les packages...

Créer un pipeline pour publier sur le flux privé

L’opération de publication du package a été effectuée depuis notre poste. Bien que pratique, ce type d’action ne devrait être réalisée qu’à des fins démonstratives et ne doit pas devenir la norme. De ce fait, nous allons créer un pipeline qui se chargera de cette opération. En nous inspirant de ce que nous avons étudié dans le chapitre Pipelines : automatisation, nous allons créer un nouveau pipeline qui exploite le code source présent sur notre projet, en utilisant le template vide, afin de pouvoir le personnaliser.

La publication d’un package peut se faire de façon automatique, directement depuis le pipeline YAML, ou nous pouvons également mettre en œuvre l’approche en deux parties en utilisant un pipeline de release. Les étapes incluses dans le pipeline YAML pour la publication doivent simplement être déplacées dans le pipeline de release si vous souhaitez opter pour cette approche.

La procédure pour publier un package sur le flux privé est simple :

Génération et mise à jour de la version du package
Compilation du fichier .nupkg
Publication sur le flux privé

Encore une fois, la génération du numéro de version peut être réalisée de multiples façons (à partir de la date, en utilisant SemVer, etc.). Lorsque nous avons créé notre package à la main, nous avons opté pour le système de notation de versions SemVer. De plus, nous avons déjà eu un système de notation de versions basé sur la date, c’est pourquoi nous allons implémenter une génération automatique de numéros de version SemVer.

Il s’agit ici d’une approche simplifiée semi-automatique, car la mise à jour du numéro de version dépend de certaines variables incrémentées manuellement par le gestionnaire du pipeline.

Notre pipeline se déroulera donc en deux phases : la génération du numéro de version (qui ne sera exécutée que pour les branches develop et master), puis la production du package suivie de sa publication.

La structure de notre pipeline ressemble...

Manipulation des versions

Comme vu précédemment, il n’est pas recommandé de supprimer une version d’un package, étant donné que certaines applications peuvent se reposer sur cette dernière. La solution est de « délister » la version concernée, ce qui la rend en quelque sorte privée, car elle n’est plus accessible depuis les gestionnaires de packages (mais elle reste cependant disponible pour ceux qui veulent utiliser cette version spécifique).

Néanmoins, en considérant qu’il s’agit d’un flux privé, Azure DevOps autorise la suppression d’un package, tout comme sa suppression de la liste des versions publiques.

Par exemple, si nous souhaitons faire en sorte que la version 1.0.0 de notre package soit rendue inaccessible aux utilisateurs, nous devrons suivre la procédure suivante :

Allez sur la page de gestion du flux.

Cliquez sur le nom du package.

Cliquez sur l’onglet Versions.

Cochez la ou les versions que vous souhaitez gérer.

Cliquez sur le bouton Unlist afin de les supprimer de la liste des versions publiques.

Si nous souhaitons supprimer la version, il faudra cliquer sur les trois points verticaux, puis choisir Delete. Azure DevOps impose de valider cette action par une confirmation. Selon la décision prise, le flux sera mis à jour.

Fonctionnement des artefacts