Ce billet est le cinquième partie de ma série consacrée à DevOps avec la plateforme Cloud Microsoft Azure. 
DevOps sur Microsoft Azure – Partie 1 : Introduction à DevOps
DevOps avec Azure – partie 2 : Infrastructure as Code (IaC) avec Azure ARM
DevOps avec Azure – Partie 3 : Création et déploiement des ressources avec Visual Studio et ARM Template
DevOPS avec Azure – Partie 4 : ARM Template CI & CD avec VSTS
Dans la quatrième partie de cette série de billets de blog sur DevOps avec Microsoft Azure, nous avons vu comment mettre en place un pipeline d’intégration et livraison continues pour un projet ARM Template, en utilisant Visual Studio Team Services (VSTS).
Avec cette approche, les caractéristiques de notre infrastructure sont définies dans des fichiers de script. Chaque fois que nous aurons besoin de faire évoluer notre infrastructure, il suffira de modifier les fichiers de script, ensuite pousser nos modifications dans notre repository sur VSTS. A ce moment notre pipeline de CI &CD va prendre la relève. La génération et le déploiement des changements apportés à notre infrastructure se feront automatiquement.
L’un des objectifs d’une infrastructure programmable est de permettre de versionner l’infrastructure et utiliser le même repository que le code source de l’application. Ainsi, l’application et son infrastructure pourront évoluer conjointement.
Dans ce billet, nous allons intégrer l’application à notre repository et voir comment mettre en place une stratégie de CI & CD pour le code de l’application et les scripts de l’infrastructure.
Nous allons commencer par ajouter une nouvelle application ASP.NET MVC Core à notre solution :
Une fois la nouvelle application ajoutée, nous allons pousser nos changements sur notre repository distant. Nous allons maintenant procéder à la création du pipeline de CI et CD pour notre application.
Choix d’une stratégie de CI & CD pour l’infrastructure et le Code
Avant de commencer à mettre en place votre pipeline d’intégration et livraison continues, vous devez décider de comment les déploiements vont s’effectuer pour le code et l’infrastructure. Je vais présenter deux approches différentes : la première approche va permettre d’utiliser le même pipeline de CI et CD pour le code et l’infrastructure, tandis que la seconde approche va permettre de mettre en place des pipelines séparés. Chaque approche à ses avantages et ses inconvénients.
Comme souligné ci-dessus, la première approche que je vais utiliser va nous permettre d’avoir dans une même build definition toutes les tâches pour la génération et la publication du code de l’infrastructure ainsi que les tâches pour la génération et la publication de l’application. Idem en ce qui concerne la release definition.
L’avantage de cette approche est que l’application et l’infrastructure ont le même cycle de vie. A chaque sauvegarde des changements sur le repository distant, le déploiement de l’infrastructure est effectué avant. En cas d’échec, le processus n’évoluera plus et l’application ne sera pas déployée. Ainsi nous avons une meilleure cohésion entre le code de l’application et l’infrastructure et ces derniers vont partager les mêmes numéros de version et évoluer ensemble.
Dans de nombreux cas, le déploiement des nouveautés de l’application ne nécessitera aucune mise à jour de l’infrastructure. Or, les tâches de génération et de déploiement de l’infrastructure s’exécuteront à chaque commit du code de l’application et vice-versa. Cela aura pour conséquence un temps de build et de déploiement plus long.
Mise à jour de la Build definition
Accédez à votre Build definition dans VSTS. Vous allez dans un premier temps ajouter une nouvelle variable ayant pour nom BuildConfiguration et pour valeur release :
Vous allez ensuite ajouter des tâches pour restaurer les packages NuGet, générer l’application, exécuter les tests unitaires, publier l’application et transférer cette dernière dans le répertoire de l’artefact.
Tâche pour la restauration des packages NuGet
Vous allez ajouter une tâche .NET Core :
Dans la zone commande, vous allez sélectionner « restore ». Dans le champ « Path to project(s) », vous allez mettre le chemin vers le fichier.csproj. Mettez le chemin suivant « **/*.csproj » afin que la restauration des packages soit effectuée pour tous les projets de la solution.
Tâche pour la génération
Ajoutez une seconde tâche .NET Core. Sélectionnez la commande Build et renseignez le chemin des fichiers .csproj. Dans la zone Arguments, saisir « --configuration $(BuildConfiguration) » :
Tâche pour exécuter les tests unitaires
Vous allez ajouter une autre tâche .NET Core à la Build definition. La commande à utiliser sera tests. Dans Path to project(s), vous allez mettre un chemin permettant de rechercher et exécuter tous les projets de tests unitaires dans votre solution. Couramment, les projets de tests unitaires sont dans des dossiers contenant le mot Tests (exemple MonProjet.Tests). Le chemin permettant d’exécuter les projets de tests respectant cette nomenclature est « **/*Tests/*.csproj ».
Dans le champ Arguments, vous devez saisir « --configuration $(BuildConfiguration) ». N’oubliez pas de cocher « Publish test results ».
Tâche pour publier l’application
Vous allez ajouter une tache .NET Core qui va permettre de publier l’application. La commande à utiliser est publish.
Dans le champ Arguments, vous devez saisir « --configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory) ». Ces arguments vont être passés à la commande dotnet publish lors de son exécution pour définir la configuration à utiliser et le répertoire de publication du projet.
Pour finir, vous devez déplacer la tâche « Publish Build Artifacts » à la fin. Elle doit être la dernière tâche à être exécutée. Les fichiers de déploiement pour l’infrastructure et l’application seront placés dans le dossier Staging. Cette tâche va permettre de les déplacer dans le dossier de l’Artefact, afin que les tâches de déploiement puissent accéder à ceux-ci.
Release Definition.
Passons maintenant à la mise à jour de la Release definition pour ajouter la tâche de déploiement de l’application dans son infrastructure Azure. L’unique tâche dont nous avons besoin est la tâche « Azure App Service Deploy ».
Vous aurez besoin de renseigner votre suscription Azure et le nom de votre Azure Appp Service :
Enregistrez et mettez en file d’attente une nouvelle Release pour vous assurer que tout fonctionne correctement.
Une fois l’application déployée, ouvrez le portail Azure, sélectionnez votre App Service et accédez à votre application via l’adresse URL obtenue à partir du portail Azure :
Dans le prochain billet, nous verrons la seconde approche.