Une des opérations que j’ai dû effectuer chez un client est d’implémenter le processus d’intégration et de déploiement continue de ses applications d’une part, mais aussi des librairies développées en interne et qu’il fallait entreposer dans un gestionnaire de package.

La solution mis en place est de créer et de publier automatiquement des packages Nuget dans ProGet avec des builds TFS.

En effet, ProGet est un gestionnaire de Packages universel qui s’intègre avec plusieurs outils comme TFS, TeamCity, Jenkins et qui, à la différence du package manager de Microsoft, permet de gérer les types de packages les plus courant (Nuget, npm, Bower, Chocolatey et Maven) le tout dans un seul outil.
Il existe plusieurs niveau de licence de ProGet dont une gratuite qui est parfaitement adapté à une architecture de base et qui peut être mis à jour par la suite.

Le but de cet article est de montrer les principales étapes qui m’ont été nécessaires à l’installation et la configuration de ProGet ainsi que la création et la publication des packages Nuget avec les builds de TFS.

Installation et configuration de ProGet

Les prérequis pour l’installation de ProGet sont :

  • 2 Core CPU, 2 GB RAM, 1 GB for storage.
  • Le framework 4.0.
  • SQL Serveur (ProGet peut installer la version Express lors de son installation).

Le téléchargement de ProGet est disponible sa page de téléchargement.
Pour chaque version il est possible de télécharger soit la Full version qui contient aussi l’exe de SQL Serveur Express 2005 ou la Small installer qui ne contient uniquement le setup de ProGet.
Lors de l’installation il sera demandé une clé de licence (même pour la version gratuite) qui peut être obtenu automatiquement si le serveur possède une connexion internet ou sinon pour l’obtenir manuellement en se rendant sur https://my.inedo.com/, puis en se créeant un compte et en faisant une demande de licence.

Déployer vos packages dans ProGet avec TFS/VSTS proget_licence

Installation
La procédure d’installation de ProGet n’a rien de particulier, il suffit de cliquer sur le setup et de suivre les différentes étapes de configuration.
La procédure complète d’installation est ici : http://inedo.com/support/documentation/proget/installation/installation-guide
A l’issue de l’installation, ProGet est configuré par défaut avec le port 81. Pour le modifier, il faut dans IIS modifier les bindings du site ProGet créées lors de l’installation.

Déployer vos packages dans ProGet avec TFS/VSTS - iis-binding

Une fois l’installation terminée se rendre sur le site http://localhost est vérifier que l’instance ProGet est bien installée avec un feed Nuget créé par défaut.
La dernière étape de l’installation est l’activation de ProGet directement via le portail dans la section Administration, Licencing and activation.

Déployer vos packages dans ProGet avec TFS/VSTS -activationProget
Et suivre la procédure décrite

Déployer vos packages dans ProGet avec TFS/VSTS - activationProget2

Configuration de la sécurité pour la publication de packages
Par défaut, le compte administrateur créé est Admin / Admin, c’est avec ce compte que nous allons configurer la sécurité de publication.
Afin de pouvoir publier des packages automatiquement depuis TFS, nous allons créer un utilisateur qui aura l’autorisation de publier des packages.

Dans la section d’administration, puis dans la gestion des users et tâches nous allons créer un groupe « Publisher »

Déployer vos packages dans ProGet avec TFS/VSTS - addGroupe

Puis un utilisateur « tfspublisher » qui sera membre de ce groupe.

Déployer vos packages dans ProGet avec TFS/VSTS - adduser

Nous modifions aussi les permissions pour le tâche « Publish Packages » en autorisant le remplacement de packages.

Déployer vos packages dans ProGet avec TFS/VSTS - customizetask

Publication des packages avec TFS/VSTS

Le but de l’intégration continue est qu’à chaque archivage de code par un utilisateur, la build compile, exécute les tests unitaires et publie le résultat dans un environnement afin de pouvoir être testée.
Dans le cas de framework ou librairies, l’idée est de les publier lors de chaque build d’intégration continue, le package résultant de cette build dans le feed Nuget de Proget.
Puis, ce package sera récupéré par les projets qui l’utilisent lors de la restauration des packages Nugets.

Création du End Point
Dans la gestion des End points du projet de TFS correspondant au projet des packages, il faut créer un End point de type « Generic » dans lequel sera renseigné la connexion au feed Nuget de notre instance ProGet
Déployer vos packages dans ProGet avec TFS/VSTS endpoint

Le serveur Url correspond au feed Nuget crée dans ProGet

Déployer vos packages dans ProGet avec TFS/VSTS - nugetfeed

Le Username reste vide et le Token Key est la key sous forme <login> :<password>, ici dans notre cas on saisira tfspublish:tfspublish

La build
La publication des packages se fait dans une build de TFS/VSTS en utilisant les tâches de build natif :
– Nuget Packager qui servira à créer les packages
– Nuget Publisher, qui publiera dans ProGet les packages générés (puisque le déploiement d’un package Nuget dans ProGet se fait avec l’outil nuget.exe).

La création des packages

Déployer vos packages dans ProGet avec TFS/VSTS -build_createpackage

Le paramètre essentiel de cette tâche est la localisation du ou des fichier(s) .nuspec à packager.

La publication des packages

Déployer vos packages dans ProGet avec TFS/VSTS - build_publishpackage

Les paramètres à renseigner sont :

  • La localisation des packages générés précédemment, il peut s’agir d’un ou de plusieurs packages
  • Le type de feed, dans notre cas nous choisirons Externe (l’Interne correspond au package management de VSTS)
  • L’end Point créé précédemment

Une fois la build exécutée correctement, les packages apparaissent dans le Feed Nuget de notre instance ProGet

Déployer vos packages dans ProGet avec TFS/VSTS - nugetfeed2

Ce processus permet donc de packager et publier automatiquement des packages Nuget dans ProGet avec des build TFS/VSTS.
Cependant, afin de compléter et d’optimiser notre processus, il reste une étape qui consiste à versionner nos package selon son état de stabilité, ce qui fera surement l’objet d’un autre article.