En route vers le DevOps avec Visual Studio Team Services

VSTS est un service de collaboration basé sur le Cloud pour le contrôle de versions, la planification Agile, la livraison continue et l'analyse d'application. VSTS est une solution complète avec de nombreuses fonctionnalités, dont :

• le support de Git et TFVC (Team Foundation Version Control) pour le contrôle de versions ;
• la prise en charge Kanban ou encore Scrum pour la gestion agile ;
• le support de nombreux langages de programmation (C#, Java, Python, etc.) et EDI (Visual Studio, Eclipse, IntelliJ, etc.) ;
• la prise en charge de plusieurs outils de test (JUnit, xUnit, MSTest, etc.) ;
• le déploiement dans de nombreux environnements ;
• etc.

VSTS est gratuit pour les petites équipes d'au plus cinq personnes. Vous devez créer un compte sur VSTS et un projet d'équipe que vous allez utiliser pour la suite.

Pour cet article, nous allons utiliser Git comme outil de contrôle de versions.

Nous allons utiliser une application Web qui repose sur le Framework open source de Microsoft ASP.NET Core.

Le déploiement de l'application se fera sur la plateforme Cloud Microsoft Azure. Plus précisément, nous allons utiliser le service Azure Web Apps. Grâce au programme Visual Studio Dev Essentials, vous pouvez disposer d'un crédit mensuel gratuit de 25$ par mois, pendant un an, pour accéder à Azure. Ce qui est largement suffisant pour effectuer de nombreux tests. Vous pouvez également vous inscrire gratuitement pour un mois au service et obtenir un crédit de 200$ pour tester celui-ci.

Pour ceux qui disposent déjà d'un compte Github et qui ne souhaitent pas changer leurs habitudes, pour la suite de l'article, ils doivent cloner le repository de l'application d'exemple dans leur compte.

Après cela, ouvrez VSTS et procédez comme suit pour lier votre compte GitHub à VSTS :

1. Cliquez sur l'icône de configuration du compte dans le menu principal, puis sur Services ;

   

2. Cliquez sur EndPoints, ensuite sur New Service Endpoint, puis sur GitHub ;

3. Dans la fenêtre qui s'affiche, sélectionnez Grant autorisation ;

4. Cliquez ensuite sur le bouton Authorize ;

5. Une fenêtre va s'afficher vous invitant à vous connecter à votre compte github ;

6. Connectez-vous, vérifiez les accès qui sont demandés, et cliquez sur Authorize application ;

7. Cliquez sur Ok pour ajouter la nouvelle connexion à votre projet.

Pour ceux qui désirent utiliser Git avec VSTS, ils doivent se rassurer d'avoir un client Git installé sur leur machine. En ce qui me concerne, j'utilise directement les outils offerts par Visual Studio.

Pour publier le code sur VSTS, vous devez :

1. Télécharger le zip du code source sur mon compte Github ;
2. Dézipper le fichier téléchargé ;
3. Ouvrir l'invite de commande dans le répertoire racine du code source ;
4. Exécuter les commandes suivantes :

Git add .
git commit -m 'initial'
git remote add origin https://[votreprojet].visualstudio.com/DefaultCollection/_git/CI%20and%20CD%20With%20VSTS
git push -u origin --all

Pour connaître le lien que vous devez utiliser pour la commande git remote add origin, vous devez vous connecter à votre projet d'équipe sur VSTS, ensuite allez sur Code, puis cherchez la section Command line instructions et copiez la ligne de commande au niveau de Push an existing repository.

1. Une fenêtre de connexion s'affiche. Renseignez vos informations d'authentification à votre compte Microsoft (VSTS) et validez.

Nous venons de créer notre build definition. Maintenant, nous allons configurer cette dernière. Nous allons dans un premier temps créer les différentes variables que nous allons utiliser dans les build steps. L'utilisation des variables va nous permettre de réutiliser les informations définies dans plusieurs tâches. De plus, en cas de changement, on effectue la modification uniquement au niveau de la variable.

IV-A-1. Définitions des variables▲

Dans la fenêtre de la Build Definitions, cliquez sur l'onglet Variables, et créez les variables suivantes :

1. BuildConfiguration avec pour valeur Release ;
2. PublishOutput, avec pour valeur $(Build.StagingDirectory)/SampleApp. Il s'agit du répertoire dans lequel l'application sera générée après la compilation ;

3. DeployPackage avec pour valeur $(Build.StagingDirectory)/SampleApp.zip, qui représente l'emplacement du package Zip qui sera utilisé pour le déploiement. $(Build.StagingDirectory) représente une variable de build prédéfinie de VSTS. Il s'agit du répertoire de travail dans lequel l'agent VSTS chargé d'exécuter les tâches copie les artefacts (fichiers de déploiement du projet) avant leur publication dans le répertoire de destination ;

   

4. Cliquez sur Save pour enregistrer les modifications ;

5. Dans la fenêtre qui va s'afficher, donnez un nom à votre Build Definition et cliquez sur OK.

Passons maintenant à la création des tâches qui seront exécutées à chaque build.

IV-B-1. Tâche pour restaurer les packages▲

La première tâche que nous allons créer va permettre de restaurer les packages utilisés par l'application. Pour ajouter cette tâche, vous devez :

1. Cliquer sur le bouton Add build step ;
2. Dans la fenêtre qui va s'afficher, sélectionner Utility dans le menu à gauche ;
3. Choisir la tâche Command Line et cliquer sur Add, puis sur Close pour fermer la fenêtre ;
4. Dans la zone Tool, saisir dotnet ;
5. Dans la zone Arguments, saisir restore et cliquer sur Save ;

IV-B-2. Tâche pour générer la solution▲

Suivez les mêmes étapes pour ajouter la tâche Visual Studio Build. Dans le menu de gauche, vous allez sélectionner plutôt Build. N'apportez aucune modification à cette build.

IV-B-3. Tâche pour exécuter les tests unitaires ▲

Ajoutez maintenant la tâche Visual Studio Test. Dans le champ Test Assembly, vous allez saisir « **\SampleApp.Test\project.json » et dans le champ « Other console options », vous allez saisir « /UseVsixExtensions:true /logger:trx ».

IV-B-4. Tâche pour publier le projet▲

Vous allez ajouter une autre tâche de type Command Line. Dans la section Tool, vous allez saisir dotnet, et dans la section Arguments, vous allez saisir « publish src/SampleApp --configuration $(BuildConfiguration) --output $(PublishOutput) ».

IV-B-5. Tâche pour créer un dossier Zip de déploiement▲

La tâche que nous allons utiliser à cette étape n'est pas disponible dans les modèles proposés par défaut par Microsoft. Nous allons installer cette tâche depuis le marketplace VSTS.

Pour cela, vous allez :

1. Cliquer sur le bouton permettant d'ajouter une nouvelle tâche ;
2. Dans la fenêtre du catalogue des tâches, vous allez cliquer sur « Don't see what you need? Check out our Marketplace » ;

3. Dans la fenêtre du marketplace, sélectionnez la tâche Trackyon Advantage et cliquez sur Install.

   

4. Revenez dans votre projet VSTS, puis cliquez à nouveau sur le bouton permettant d'ajouter une nouvelle tâche ;

5. Dans le catalogue, vous allez cliquer sur Utility dans le menu de gauche, puis sélectionner la tâche Trackyon Zip et l'ajouter ;

6. Dans la zone Folder to Zip, saisissez $(PublishOutput) ;

7. Dans la zone Path to final Zip file, saisissez $(DeployPackage) ;

8. Enregistrez les modifications.

IV-B-6. Tâche pour créer l'artefact ▲

La dernière tâche que nous allons créer permettra de récupérer le package de l'application dans le répertoire de travail de l'agent VSTS et le rendre disponible en tant qu'artefact. Pour le faire :

1. Répétez les étapes pour ajouter une nouvelle tâche ;
2. Dans le catalogue, vous allez sélectionner Publish Build Artifacts ;
3. Dans le champ Path to Publish, vous allez saisir $(DeployPackage) ;
4. Dans le champ Artifact Name, saisir drop ;
5. Dans le champ Artifact Type, sélectionner Server ;
6. Enregistrez les modifications.

Ceci fait, vous pouvez lancer une build manuelle de votre solution en cliquant sur « Queue new build », dans la barre de menu de la page de Build .

Un agent VSTS sera initialisé et ce dernier se chargera d'exécuter chaque tâche dans la Build Definitions. Une console intégrée au portail vous permet de suivre l'évolution des tâches.

Les tâches sont exécutées de façon séquentielle. Si une tâche échoue, les tâches qui suivent ne seront pas exécutées. De même, si un test unitaire échoue, toutes les tâches qui suivent ne seront pas exécutées.

Une fois que toutes les tâches ont été exécutées avec succès, vous aurez une fenêtre de rapport avec les détails concernant la build. En cliquant sur Tests, vous aurez un rapport détaillé sur les tests unitaires qui ont été exécutés.

Une fois toutes les tâches exécutées correctement, le package de déploiement sera créé et publié comme artefact. Pour visualiser ou télécharger ce dernier, cliquez simplement sur Artifacts dans le menu disponible dans les résultats de la Build.

Toutes ces étapes complétées, vous pouvez passer au déploiement.

Avant de procéder à la mise en place de nos Releases, nous devons d'abord faire communiquer VSTS avec Microsoft Azure. Vous devez disposer d'un compte sur la plateforme Cloud. Dans celui-ci, vous allez créer une Web application en suivant la procédure standard.

À la suite de cela, vous allez créer un « Service endpoints » qui permettra de faire communiquer VSTS et Azure. Pour le faire :

1. Cliquez sur l'icône de configuration du compte dans le menu principal, puis sur Services ;
2. Cliquez sur EndPoints, ensuite sur New Service Endpoint et sélectionnez Azure Classic ;
3. Dans la fenêtre qui va s'afficher, sélectionnez « Certificated Based » ;
4. Cliquez ensuite sur le lien « publish settings file » en bas pour télécharger un fichier de configuration. Ce fichier contient vos informations d'identification sécurisées ainsi que d'autres informations concernant votre abonnement Azure, que vous pouvez utiliser dans votre environnement de développement ;
5. Ouvrez le fichier avec bloc note ;
6. Revenez sur VSTS et remplissez les champs :
   Connection Name : un nom quelconque que vous souhaitez donner au service ;
   Environment : Azure Cloud ;
   Server Url : laissez l'information par défaut ;
   Subscription Id : copiez/collez votre suscription Id du fichier de config téléchargé précédemment ;
   Subscription Name : copiez également cette information dans le fichier de config ;
   Management Certificate : récupérez aussi cette information dans le fichier de config.

1. Cliquez ensuite sur Verify connection pour vous assurer que la connexion s'effectue correctement et cliquez enfin sur Ok.

Pour commencer, vous allez créer une « Release Definition » en cliquant sur « Build & Releases » dans le menu principal, puis sur Releases. Dans la fenêtre qui va s'afficher, cliquez sur « New definition » :

Dans la liste des templates de déploiement, vous allez choisir Empty, puis cliquer sur Next. Dans la fenêtre de sélection de la source dans laquelle est publié l'artefact à déployer, choisissez Build. Sélectionnez ensuite la Build définition que vous avez créée précédemment, puis cochez la case Continuous deployment et cliquez enfin sur Create. Renommez « environement 1 » qui est créé par défaut en « Dev ».

Un environnement ici représente un ensemble de tâches, de flux travail et configurations nécessaires pour le déploiement de l'application sur un serveur défini (Dev, QA, etc.).

Le premier environnement que nous venons de créer va permettre de déployer l'application sur l'infrastructure Dev. Nous allons donc ajouter à cet environnement les tâches nécessaires pour effectuer le déploiement sur Azure. Il s'agit :

• d'une tâche qui permettra d'arrêter le service qui héberge l'application ;
• d'une tâche pour déployer l'application ;
• et d'une tâche pour relancer le service.

Cependant, la tâche pour arrêter et relancer le service n'existe pas dans les modèles par défaut. Vous devez donc l'installer à partir du marketplace VSTS. Pour le faire :

1. Cliquez sur Add tasks ;
2. Dans le catalogue des tâches, choisissez « Don't see what you need? Check out our Marketplace » ;
3. Lancez une recherche avec les termes « start and stop » et sélectionnez dans la liste la tâche « Azure App Services - Start and Stop » ;
4. Cliquez sur Install pour procéder à son installation.

Revenez sur la fenêtre de la Release definition, cliquez sur Add tasks, sélectionnez et ajoutez « Azure AppServices / WebApp Stop » et « Azure AppServices / Web App Start » dans la section Utility, puis « Azure Web App Deployment » dans la section Deploy.

Pour les tâches Azure AppServices, renseignez les champs :

• Azure Connection Type, avec la valeur Azure Classic ;
• Azure Classic Subscription, avec le nom du service Endpoint pour Azure que vous avez créé précédemment ;
• Web App Name, le nom de la Web App Azure.

Pour la tâche Azure Deployment, vous devez renseigner les champs :

• Azure Subscription (Classic) avec le nom du service Endpoint pour Azure ;
• Web App Location, avec le nom du Datacenter dans lequel votre application est hébergée. Vous pouvez récupérer cette information depuis le portail Azure ;
• Web App Name, avec le nom de votre Azure Web App ;
• Web Deploy Package, avec l'emplacement du package qui sera utilisé pour le déploiement : $(System.DefaultWorkingDirectory)/Sample Build Definitions/drop/SampleApp.zip.

Enregistrez les modifications. Cliquez sur le bouton Release, puis sur Create Release pour lancer un déploiement manuel.

Si le déploiement s'effectue avec succès, vous pourrez avoir un aperçu de votre application exécutée sur Azure, en saisissant son URL dans la barre d'adresse de votre navigateur.

Ceci fait, pour créer l'environnement de QA, vous pouvez simplement cloner l'environnement de Dev, renommer ce dernier et apporter les modifications nécessaires pour un déploiement sur le serveur de QA.

Ensuite, vous devez passer à l'étape de configuration en cliquant sur le bouton à droite du nom de l'environnement, puis en sélectionnant « Assign approvers » :

Sur cette page, vous pouvez spécifier un utilisateur qui devra approuver le déploiement. Celui-ci pourrait être alerté par un mail.

Dans la zone Deployment conditions, vous pouvez définir les conditions à respecter avant le déploiement. Par exemple : démarrer le processus de déploiement pour la dernière Release qui a été déployée avec succès dans l'environnement de Dev ou encore tous les lundis à 7h. À cette date, le déploiement entrera dans la file d'attente et l'approbateur recevra un email pour valider ou rejeter ce dernier.

Dans l'image ci-dessous, on peut remarquer qu'après les déploiements en Dev ET QA pour la Release 3, un déploiement est en attente d'approbation pour l'environnement de Staging.