`Les Dieux du ${Code}`

Lorsque l'on souhaite partager une librairie C# que cela soit à la communauté ou à l'intérieur d'une entreprise, il est possible de mettre en place une solution complète d'intégration continue avec Visual Studio Team Services Azure Dev Ops assez rapidement.

Voici ce qu'il faut mettre en œuvre pour cela.

Création de la solution et archivage 

La première chose c'est d'avoir la matière soit une solution Visual Studio comportant à minima un projet correspondant à la librairie de classes que l'on souhaite partager et un projet pour les méthodes de tests unitaires de la librairie.

Ensuite nous allons créer un nouveau repository git sur le projet d'équipe sur lequel nous travaillons dans Azure Dev Ops.

Nous allons enfin tirer une branche à partir de la branche main pour l'initialisation de notre repository. Nous y archiverons la solution et les deux projets.

Mise en place de l'intégration continue (CI)

Pour mettre en place la partie intégration continue , nous allons paramétrer un canal de build (build pipeline) accessible dans le menu pipelines > build.  

Vous arrivez alors sur l'écran suivant :

Nous allons donc paramétrer le build pour la branche main de notre repository de cette façon :

Nous allons à présent détailler les différentes étapes du building pour mieux les comprendre.

Étape 1 : Get sources 

 Cliquez ensuite sur "New Pipeline", vous arrivez alors sur l'écran suivant 

L'étape de récupération des sources du projet sur le serveur de build est la première chose à paramétrer.

Elle se paramètre également au travers de l’onglet « Référentiel » au niveau de la définition de build en mode "Edition".

On retrouvera ici parmi les principaux paramètres :

• Le team projet : le projet d'équipe ciblé par le build
• Le type de référentiel
• Le référentiel ciblé par ce build
• La branche concernée par ce build
• Clean Sources
• Cette option permet de spécifier si on veut que les sources soient supprimées du serveur de build après le build ou non.
• Tag Sources
• Cette option permet de spécifier si l'on souhaite pour chaque build ou pour chaque build réussi étiqueter les sources afin d'identifier quelle version de chaque fichier se trouve dans le build.
• Report Build Status
• Ce booléen permet d'afficher un badge sur le référentiel de source afin d'indiquer si le build est en succès ou en erreur.

Une fois que l'étape de récupération des sources est paramétrée, nous allons pouvoir paramétrer les différentes étapes pilotées par l'agent.

Cliquez sur le "+" afin d'ajouter des étapes au build.

Étape 2 : nuget restore

Afin d'ajouter l'étape "nuget restore", tapez "nuget" dans la barre de recherche et sélectionnez la tâche Nuget

Cette étape consiste à la récupération des packages nuget déclarés au niveau de la solution que l’on souhaite builder.

On retrouvera ici parmi les paramètres suivants :

• Le nom affiché pour cette action dans le process de build
• La commande nuget à exécuter (on dispose des commandes restore, pack, push et custom)
• Le chemin vers la solution (ici j'ai choisi de faire référence à une variable qui stocke le chemin vers ma solution)

• Le flux de récupération des packages nuget. On utilisera donc le flux de packages de l'entreprise, incluant les packages provenant de nuget.org
• On aura enfin la possibilité au niveau du bloc "Control Options" de rendre cette étape obligatoire pour passer à la suite ou non. Je préconise de la rendre obligatoire.

Étape 3 : assembly info reader

Afin d'ajouter l'étape "assembly info reader", tapez "assembly info reader" dans la barre de recherche et sélectionnez la tâche qui apparait.

Il ne s'agit pas d'une tâche de base, il faut l'installer depuis le market place. Procédez donc à l'installation de cette tâche et ajouter là dans le process de build.

Étape 4 : build solution

Cette étape cruciale consiste à la génération de la solution, et donc des sorties de la solution paramétré dans le build.

Afin d'ajouter l'étape "build solution", tapez "visual studio build" dans la barre de recherche et sélectionnez la tâche en cliquant sur "Add"

On retrouvera ici parmi les paramètres suivants :

• Le nom affiché pour cette action dans le process de build
• Le chemin vers la solution (ici j'ai choisi de faire référence à une variable qui stocke le chemin vers ma solution)
• La version de visual studio à utiliser sur le serveur de build
• Les arguments msbuild si nécessaire
• La plateforme ciblée par le build
• La configuration ciblée par le build
• Un booléen qui permet d'indiquer si l'on veut réaliser un build incrémental ou non.

Étape 5 : jouer les tests

Au niveau de l’étape des tests unitaires, c’est l’étape qui permet de jouer les tests existants au niveau de la solution et qui va nous fournir les résultats de ces tests et la couverture du code de ces tests. Les paramètres peuvent rester par défaut sur cette étape du build.

Pour ajouter cette tâche, tapez "visual studio test" dans la barre de recherche et sélectionnez la tâche en cliquant sur "Add"

Étape 6 : nuget pack

Afin d'ajouter l'étape "nuget pack", tapez "nuget" dans la barre de recherche et sélectionnez la tâche Nuget

Cette étape consiste au packaging des packages nuget que l'on souhaite déployer lors de l'étape 7.

On retrouvera ici parmi les paramètres suivants :

• Le nom affiché pour cette action dans le process de build
• Le chemin vers le fichier csproj ou nuspec décrivant la librairie à déployer sur nuget (ici j'ai choisi de faire référence à une variable qui stocke le chemin vers mon fichier projet)
• Des options de packaging incluant un choix de mode de versioning du package nuget. Ici on utilisera la variable d'environnement qui compose le numéro de version à partir du numéro de version de l'assembly récupéré précédemment.
• On trouvera une différence entre le paramétrage du build main et staging au niveau de la variable d’environnement qui sera construite différemment. En effet, sur la branche Main, c'est forcément une version beta du package. Par contre lorsque l'on a builder sur la branche, cela pourra être une version RC ou définitive.

Étape 7 : mise en place du trigger d'intégration continue

Enfin dernière étape pour la partie intégration continue, nous passons au paramétrage du déclencheur de build en suivant les instructions suivantes, afin de pouvoir être en intégration continue, on va alors générer un build pour chaque archivage sur la branche concernée (ici master)

Étape 8 : stratégie de branche

Enfin dernière étape pour la partie intégration continue, nous passons au paramétrage de la stratégie de branche pour la branche master.

Pour arriver sur cet écran, il faut passer par l’interface d’administration du team project, puis allez sur l’onglet « Gestion de version », sélectionnez la branche concernée (ici master), faire un clic droit puis aller dans « Branch Policies ».

Nous allons donc ajouter une règle de validation du build lors de demandes d'archivage sur cette branche.

Une fois que vous aurez mis en place un second build sur la branche staging en reprenant les mêmes règles pour le remplir, vous aurez pleinement mis en place l'intégration continue sur votre composant.

Mise en place de la livraison continue (CD)

Pour mettre en place la partie livraison continue, nous allons paramétrer un canal de livraison (release pipeline) accessible dans le menu pipelines > releases

Vous arrivez alors sur l'écran suivant :

Nous allons donc paramétrer la livraison pour notre librairie, pour cela cliquez sur "New Pipeline", puis choisissez "Empty job".

Vous arrivez alors sur l'écran suivant :

Cet écran va nous permettre quel artifact de sortie de build va devoir être déployé sur chaque environnement. Chaque environnement pouvant être indépendant ou liés les uns ou autres par des relations de différents types.

Etape 1 : Sélection des artefacts

Ce sont les artefacts de builds associés à ce déploiement. Un déploiement peut inclure plusieurs artefacts issus de builds différents.

On précisera sur cet écran que c'est la version Latest qui est la version par défaut à prendre pour l'artefact de sortie.

On peut également paramétrer des déclencheurs de la release en fonction de la mise à disposition d'un artefact. Pour voir ces déclencheurs, cliquez sur l'icone  

Etape 2 : Paramétrage d'un environnement

Dans l'environnement paramétré on retrouvera comme on l'avait pour les tâches de builds, des tâches jouées sur le serveur Dev Ops. Dans notre cas particulier, nous allons paramétrer une tâche de "nuget push" qui consistera à la publication des packages nuget vers le feed de publication nuget. On laissera les paramètres par défaut pour cette étape du build.  Ces paramètres permettent d'indiquer le chemin de récupération du ou des fichiers nupkg à déployer sur le feed de publication nuget.

Bonus : Liens entre environnements

Au niveau d'un environnement, on a la possibilité de définir des "pre-deployment conditions" et des "post deployment conditions". Ces conditions permettent d'indiquer des acteurs humains habilités à valider le déploiement d'un environnement avant son déploiement ou le bon déploiement d'un environnement après les actions de déploiement. On a également la possibilité d'utiliser des fonctions azure ou des requêtes sur des work items comme garde fous pouvant bloquer le déploiement d'un environnement. 

Mise en route de l'usine logicielle

Nous pouvons alors effectuer la pull request allant de notre branche de dev vers la branche main. Cela va déclencher le build en mode Pull Request puis en mode Continuous Integration une fois que l'archivage aura été réalisé.

La mise à disposition d'un binaire de sortie pour le build va déclencher le déploiement de ce binaire sur l'environnement ciblé et tout cela automatiquement.

Notre usine logicielle est donc en place.