En route vers le DevOps avec Visual Studio Team Services

cas d'un projet ASP.NET Core et Azure

Hinault Romaric

Dans ce tutoriel, nous verrons comment mettre en pratique le DevOps en utilisant Visual Studio Team Services. Nous utiliserons une application ASP.NET Core et le déploiement se fera sur Azure.

Commentez

- Titre : En route vers le DevOps avec Visual Studio Team Services

- Auteur : Hinault Romaric

- Parution : 1 février 2017

- Public visé :

- Licence : Copyright ® 2017 Hinault Romaric. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. Présentation des outils

- II-A. Visual Studio Team Services (VSTS)

- II-B. Git

- II-C. ASP.NET Core

- II-D. Microsoft Azure

- III. Initialisation

- III-A. Utilisation de GitHub comme source contrôle

- III-B. Utilisation de Git avec VSTS

- IV. Création de la build

- IV-A. Configurations de la build definition

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

- IV-B. Création des build step

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

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

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

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

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

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

- IV-C. Exécution de la build

- V. Release Management

- V-A. Connexion avec Azure

- V-B. Définition des environnements de déploiement

- VI. Conclusion

- VII. Remerciements

- VIII. Références

I - Introduction

Le monde du numérique dans lequel nous vivons entraîne de nombreux changements au sein des entreprises. Pour demeurer compétitives, il n'est plus question de prendre une année de développement ou plus avant de livrer une application ou ses évolutions. Les entreprises doivent non seulement réduire le Time To Market (TTM), mais également s'assurer de livrer une solution robuste et facilement maintenable.

Une solution à ces besoins réside dans le DevOps. D'ailleurs, c'est la pratique agile au centre de l'actualité de nos jours. DevOps est avant tout une philosophie : une culture qui prône une étroite collaboration entre les développeurs et les chargés d'opération (les équipes métiers), afin d'accélérer la livraison des applications et mieux adapter celles-ci aux besoins des utilisateurs.

Toutefois, derrière cette philosophie, il y a des concepts fondamentaux qui font intervenir plusieurs outils. Il s'agit de l'intégration et le déploiement continus, qui seront l'objet de cet article.

L'intégration continue regroupe un ensemble de pratiques visant à favoriser l'industrialisation du développement d'une application. La mise en place de l'intégration continue nécessite le recours à un serveur d'intégration continue et un gestionnaire de version. Le serveur d'intégration continue offre des fonctionnalités permettant d'assurer la compilation du code, l'exécution des essais unitaires, le packaging et même le déploiement.

Au niveau du déploiement, il est également possible de configurer son serveur d'intégration pour automatiser le déploiement. Ce dernier se chargera d'exécuter les scripts de configuration des environnements d'exécution et déployer l'application, sans nécessiter une intervention humaine.

Il existe sur le marché plusieurs serveurs d'intégration continue, dont Jenkins, SonarQube, Team Foundation Server ou encore TeamCity. Pour cet article, nous allons utiliser Visual Studio Team Services.

II - Présentation des outils

II-A - Visual Studio Team Services (VSTS)

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.

II-B - Git

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

II-C - ASP.NET Core

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

II-D - Microsoft Azure

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.

III - Initialisation

Pour commencer, vous devez créer un compte VSTS et un projet d'équipe, ainsi qu'un compte Azure.

Comme élément de départ, nous allons utiliser une application d'exemple qui a été développée dans le cadre de mon tutoriel sur les tests unitaires avec MsTest V2. Il s'agit d'une application ASP.NET Core. Son code est disponible sur GitHub.

Nous allons utiliser deux approches pour exploiter ce code dans VSTS. La première approche sera d'utiliser VSTS comme service d'hébergement et de gestion de versions du code source. La seconde approche sera l'utilisation de GitHub avec VSTS, pour ceux qui affectionnent cette plateforme.

III-A - Utilisation de GitHub comme source contrôle

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.

III-B - Utilisation de Git avec VSTS

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.

IV - Création de la build

L'objectif de l'intégration continue est de s'assurer qu'à chaque commit, la compilation du code source s'effectue correctement (aucune erreur n'a été détectée), les tests unitaires sont exécutés avec succès (pour s'assurer qu'il n'y a aucune régression et bien plus).

Dans VSTS, cela se résume en un ensemble de tâches qui seront exécutées chaque fois qu'une modification du code source sera détectée. Dans cette partie, nous verrons donc comment créer une build avec les tâches associées. Pour créer la build :

1. Cliquez sur Build & Release dans le menu, puis sur Build ;

2. Cliquez sur le bouton « + New definition » ;

3. La fenêtre de création d'une nouvelle build définition va s'afficher, avec des modèles par défaut ;

4. Sélectionnez Empty et cliquez sur Next ;

5. Pour ceux qui utilisent Git de VSTS, sélectionnez votre projet d'équipe dans la zone Repository source. Pour les autres, sélectionnez GitHub ;

6. Cochez la case Continuous integration ;

7. Laissez les autres informations par défaut, et cliquez sur Create.

IV-A - Configurations de la build definition

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.

IV-B - Création des build step

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.

IV-C - Exécution de la build

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.

V - Release Management

La démarche DevOps vise à mettre à la disposition des utilisateurs de nouvelles fonctionnalités plus rapidement. La livraison continue permet d'automatiser les déploiements et définir un cheminement de déploiement à travers plusieurs environnements, jusqu'à la promotion en production d'une solution stable et fiable.

Les déploiements se font en suivant une stratégie qui doit au préalable être adoptée par l'équipe projet. Cette stratégie doit définir divers flux de travail, dont certaines tâches seront automatisées et d'autres manuelles.

Supposons, par exemple, que nous sommes dans une démarche de livraison continue pour un projet qui a adopté un processus de déploiement 4-tiers (Développement, Test, Préproduction et Production) :

- L'environnement de développement (Dev), qui est en fait l'environnement d'intégration, doit permettre de vérifier, une fois la build effectuée, à chaque commit, que le package est déployé correctement et que l'ensemble fonctionne ;

- L'environnement de Tests (QA) doit permettre aux responsables de l'assurance qualité de s'assurer que la solution fonctionne correctement et est conforme aux exigences et aux attentes du client ;

- L'environnement de préproduction (staging), qui doit être proche de l'environnement de production, doit permettre de faire des simulations en situation de production, avant une promotion en environnement de production, ou la solution passe en utilisation.

Dans une démarche de livraison continue pour un projet SCRUM, par exemple, le déploiement sur le serveur de Dev devrait être automatique après chaque Build effectuée avec succès, soit chaque commit. Le déploiement en QA se fera couramment quelques jours avant la fin du Sprint, ou dès lors qu'une fonctionnalité peut être testée, laissant le temps aux développeurs de corriger les bugs trouvés par les testeurs. Le déploiement en QA pourrait aussi se faire automatiquement suivant un calendrier. Ou ce dernier peut être placé dans une file d'attente suivant le calendrier, et un approbateur, qui a été averti par message électronique, se chargera de valider celui-ci.

Par contre, en ce qui concerne la promotion en staging, elle nécessitera la validation préalable des approbateurs. Il en sera de même pour la promotion en production.

La Release Management (gestion des publications) de VSTS offre un ensemble de fonctionnalités permettant de mettre en place des stratégies de déploiement continu adaptées aux besoins des équipes de développement : automatisation des déploiements, définition des flux de travail d'approbation, gestion de la sécurité, etc.

V-A - Connexion avec Azure

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.

V-B - Définition des environnements de déploiement

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.

VI - Conclusion

Au travers de cet article, je partage mon retour d'expérience et les différentes actions qui ont été menées pour mettre en place une démarche de DevOps en utilisant VSTS pour une application ASP.NET Core qui allait être hébergée sur Azure. L'objectif est de fournir aux équipes projet un guide qui pourra les aider dans leur démarche d'intégration et livraison continues avec VSTS.

VII - Remerciements

Je tiens à remercier f-leb pour sa relecture et correction orthographique.

VIII - Références

- Visual Studio Team Services ;

- Documentation intégration continue avec VSTS ;

- Documentation Release Managment avec VSTS ;

- Documentation DevOps avec VSTS ;

- Microsoft Azure ;

- Azure Web Apps ;