La démarche DevOps vise à livrer continuellement de la valeur ajoutée aux utilisateurs finaux. L'un de ses concepts clés est la livraison continue. Cette dernière permet d’automatiser les déploiements et définir un pipeline (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 ce 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.
Dans ce billet, nous verrons comment mettre en place la livraison continue pour déployer une application Web ASP.NET Core sur la plateforme Cloud Azure. Les premières étapes de la démarche sont couvertes par mon billet de blog Intégration continue d’un projet ASP.NET Core avec Visual Studio Team Services
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 :
- cliquez sur l’icône de configuration du compte dans le menu principal, puis sur Services ;
- cliquez sur EndPoints, ensuite sur New Service Endpoint et sélectionnez Azure Classic ;
- dans la fenêtre qui va s’afficher, sélectionnez « Certificated Based » ;
- 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 ;
- ouvrez le fichier avec bloc note ;
- 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. - cliquez ensuite sur Verify connection pour vous assurer que la connexion s’effectue correctement et cliquez enfin sur Ok.
Définition des environnements de déploiement
Pour commencer, vous allez un 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éé 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 :
- une tâche qui permettra d’arrêter le service qui héberge l’application ;
- une tâche pour déployer l’application ;
- Et 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 :
- cliquez sur Add tasks ;
- dans le catalogue des tâches, choisissez « Don't see what you need? Check out our Marketplace » ;
- lancez une recherche avec les termes « start and stop » et sélectionnez dans la liste la tâche « Azure App Services - Start and Stop » ;
- 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 fille 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.
La Release Management de VSTS offre un ensemble de fonctionnalités intéressantes permettant de mettre en place avec souplesse divers scénarios de livraison continue pour divers environnements. Au travers de ce billet, je donne un aperçu de la mise en place d’un pipeline de releases pour un projet ASP.NET Core.
