Gérer vos packages Nuget dans VSTS/TFS (1/2)

Un gestionnaire de packages comme son nom l’indique permet de mettre à disposition des développeurs des packages de différents types comme Nuget, Npm, maven, au travers d’un repository.

Il existe plusieurs types d’accessibilité de gestionnaires de packages :

• Public comme Nuget.org ou npmjs
• Privé comme ProGet ou Artifactory qui vont permettre cette gestion de package au sein d’entreprise.
• Dans le cloud comme MyGet

Afin de pouvoir répondre à un besoin d’entreprise, depuis environ 1 an Microsoft a intégré dans son usine logiciel VSTS et TFS un gestionnaire de packages.

A l’heure actuelle, ce gestionnaire de packages ne permet de gérer que des packages Nuget et Npm, et la prise en charge de Maven a été annoncée lors de la \\build 2017.

Dans cette série d’articles nous allons voir comment gérer des packages Nuget et Npm dans ce gestionnaire en les intégrant dans un pipeline d’intégration et de déploiement continue.

Installation du gestionnaire de package

La fonctionnalité du gestionnaire de packages n’est pas native dans VSTS, il faut l’installer par une extension qui est disponible dans le Marketplace.

Pour TFS, le gestionnaire de packages est présent par défaut à partir de TFS 2017.

Le gestionnaire de packages est gratuit pour les 5 premiers utilisateurs. Pour calculer le prix, referez vous à la calculatrice.

Gérer vos Feed

Avant de publier un package, il faut d’abord créer un feed qui servira de conteneur à vos packages.
Le nombre de feed n’est pas limité, et il est possible de créer différentes typologies de feed comme par exemple un feed par type de package (nuget, npm, …), ou un feed par domaine applicatif, libre à vous de gérer vos feed selon vos besoins.

Création d’un feed

Pour créer un feed, dans la liste déroulante des feed, cliquez sur « New Feed »

Puis saisir son paramétrage de base :

[1] Le nom et la description du feed

[2] Les autorisations de lecture, c’est-à-dire quel sont les utilisateurs ou groupes autorisés à restaurer des packages de ce feed.

[3] Les autorisations de publication de packages dans le feed, par défaut c’est le compte de service de build qui peut publier des packages.

[4] Cette option permet d’inclure les packages public de npmjs à être accessible via ce feed.

Une fois créés il est possible de modifier ces informations et de compléter si besoin le paramétrage des permissions.

Dans les Contributors, bien laisser le compte « Project Collection Build Service », afin d’autoriser les builds et releases à publier des packages.

Pour les Readers, compléter avec les utilisateurs ayant les autorisations de lister et restaurer les packages de ce feed. Pour donner cette autorisation à tous les utilisateurs du compte VSTS remplacer le compte par default par le compte « Project Collection Valid Users »

Cet écran de paramétrage permet aussi de supprimer définitivement un feed.

Création d’un package Nuget

Un package Nuget contient une librairie de classes qui sera référencée par d’autre applications.

Son projet est un type Projet de classe, et toutes ses metadata telles que son nom, sa description, sa version sont mentionnées dans un fichier .nuspec qui se trouve à la racine de notre projet.

En voici un exemple :

Pour la version , nous avons la valeur sous forme de variable $version$ qui sera automatiquement remplacée lors de la création du package.

Intégration et publication du package.

Comme toute application, notre librairie de classes est intégrée dans un processus DevOps, qui sera compilée, testée et packagée dans une build d’intégration continue. La phase de “déploiement” de ce package sera sa publication dans notre feed privé de VSTS.

L’intégration continue

Cette intégration continue est le processus qui va permettre de compiler le code et de générer le package Nuget.

Dans VSTS nous allons créer une nouvelle définition de build

La 1ere étape de cette intégration est le versionnage des assemblies (Dll) qui vont constituer le package.

Pour plus d’informations sur le versionning d’assembly lire cette documentation .

Dans le cadre de package Nuget qui contient des librairies, des Framework, le versionning des dll est très important pour que l’utilisateur puisse facilement connaitre la version du package qui est intégrée dans son projet à travers les versions des dll.

Puis la compilation du projet va permettre de générer les dll qui seront contenus dans le package.

La tâche essentielle de cette définition de build est la génération du package Nuget avec la tâche intégrée par défaut dans VSTS « Nuget packager ».

Cette tâche prend en paramètre le fichier csproj du projet de classe, le répertoire de destination du package et le versionning automatique du package avec le numéro de build. C’est aussi durant cette étape que le fichier .nuspec est modifié avec le numéro de version.

Enfin, la build va publier en artefacts le package Nuget généré qui sera versionné avec le numéro de build.

La publication du package

Pour la publication de ce package dans le feed précédemment créé, nous allons créer une nouvelle définition de Release qui comportera 2 “environnements” ‘'(ou “Stage”).

Le 1er, nous l’appellerons “Private Prérelease”, publiera le package dans le feed et lui ajoutera un statut de qualité comme étant en “Prelease”

La tâche “Nuget Publisher” prend comme paramètres:

• le .nupkg qui a été publié en artefacts de la build,
• l’url du feed qui s’obtient en cliquant sur le bouton “Connect to feed” du gestionnaire de package

La tâche “Promote package to Release” disponible dans le Marketplace, permet de rajouter un statut de qualité d’un package pour une version précise. Dans notre cas on indique que le statut de qualité du package qui vient d’être publié est dans un état de “Prerelease”.

Nous reviendrons sur cette notion de statut de qualité de package dans un second article de blog.

Le 2ème environnement de notre pipeline est celui qui va ajouter un statut de qualité en “Release” au package.

Le déroulement du pipeline

Maintenant que nous avons construit l’architecture de notre chaîne de déploiement du package, regardons quels sont les étapes de son pipeline.

1. Le code du package est archivé dans le repository VSTS/TFS
2. La build d’intégration continue versionne les assemblies, compile le code et génère le package Nuget.

Une nouvelle release est créée et

1. Le package est déployé dans feed, soit pour l’ajouter soit pour le mettre à jour (avec obligatoirement un nouveau numéro de version)
2. Cette version de package est statuée comme étant en “Prérelease”

A l’issue de l’exécution de cette release nous voyons que le package apparaît dans la liste des packages du feed.

Et que son statut de qualité est bien en “Prerelease”

Les applications qui ont besoin de tester les changements apportés à ce package vont le restaurer en utilisant la source du feed “Prerelease”.

Cette version de package validé, on déclenche le déploiement de l’environnement “Private Release” pour ajouter au package le statut de qualité “Release”

Nous avons vu dans cette 1er article comment gérer vos packages Nuget dans le gestionnaire de package de VSTS avec la création d’un feed et la mise en place du pipeline complet de publication de vos packages dans ce feed.

Dans la 2ème partie, nous verrons en détails la notion de statut de qualité avec les Release view ainsi que restauration des packages pour les développeurs.