Planifier un pipeline de mise en production avec Azure Pipelines
Dans cette section, vous suivez Andy et Mara à mesure qu’ils planifient un pipeline CD simple qui s’exécute sur Azure Pipelines.
Quand ils auront terminé, ils en feront la démonstration devant les autres membres de l’équipe. Le pipeline servira de preuve de concept qu’ils amélioreront et développerons à mesure qu’ils en apprendront davantage et qu’ils recueilleront les commentaires de Tim et Amita.
De quoi est constitué un pipeline CD simple ?
Un pipeline CD simple contient un déclencheur pour lancer le processus et au moins une phase, ou phase de déploiement. Une phase est constituée de travaux. Un travail est une série d’étapes qui définit comment générer, tester ou déployer votre application.
Andy : Nous avons déjà l’artefact de build 
. Il s’agit du fichier .zip que crée notre pipeline de build existant. Comment le déployer dans un environnement en direct 
?
Qu’est-ce qu’une phase de pipeline ?
Une phase est une partie du pipeline qui peut s’exécuter indépendamment et être déclenchée par différents mécanismes. Un mécanisme peut être la réussite de la phase précédente, une planification ou même un déclencheur manuel. Vous en apprendrez davantage sur ces mécanismes dans le prochain module.
Mara : Nous pourrions avoir une phase qui génère l’application et une autre qui exécute les tests.
Mara : Nous avons déjà défini les tâches de la phase de build de notre pipeline. Notre phase de déploiement peut être similaire, avec des tâches qui déploient la build dans un environnement.
La question est : où devons-nous déployer l’artefact ?
Qu’est-ce qu’un environnement ?
Le terme environnement est souvent employé pour désigner l’endroit où est exécuté un service ou une application. Par exemple, votre environnement de production peut se trouver là où vos utilisateurs finaux accèdent à votre application.
Pour prolonger cet exemple, votre environnement de production pourrait être :
- Un ordinateur physique ou une machine virtuelle.
- Un environnement conteneurisé, tel que Kubernetes.
- Un service managé, comme Azure App Service.
- Un environnement serverless, comme Azure Functions.
Un artefact est déployé dans un environnement. Azure Pipelines facilite les déploiements dans pratiquement n’importe quel type d’environnement, qu’il soit local ou dans le cloud.
Dans Azure Pipelines, le terme environnement a une deuxième signification. Ici, un environnement est une représentation abstraite de votre environnement de déploiement, par exemple un cluster Kubernetes, une instance App Service ou une machine virtuelle.
Un environnement Azure Pipelines enregistre l’historique de déploiement pour vous permettre d’identifier la source des modifications. En utilisant des environnements Azure Pipelines, vous pouvez aussi définir des vérifications de sécurité et des moyens de contrôler la façon dont un artefact est promu d’une phase d’un pipeline à une autre. La composition d’un environnement dépend de ce que vous souhaitez faire de l’artefact. Un environnement dans lequel vous souhaitez tester l’artefact ne sera probablement pas défini de la même manière qu’un environnement dans lequel vous souhaitez déployer l’artefact pour vos utilisateurs finaux.
Une façon de définir un environnement Azure Pipelines est d’utiliser un fichier YAML. Un fichier YAML comporte une section environment qui indique dans quel environnement Azure Pipelines l’artefact va être déployé.
Lorsque vous planifiez votre pipeline de mise en production, vous devez décider où votre application ou service s'exécutera. Voyons ce qu’Andy et Mara décident de faire.
Andy : Globalement, quel type d’environnement voulons-nous ? Voulons-nous effectuer un déploiement local ou dans le cloud ?
Mara : Nous pourrions demander à Tim de nous créer une machine virtuelle dans le labo, mais il est toujours à court de matériel. Si nous décidons d’utiliser le cloud, la solution la plus simple et la plus rapide est que l’on configure nous-mêmes une preuve de concept.
Andy : Je suis d’accord, mais il y a tellement d’options cloud à prendre en compte et on peut utiliser Azure Pipelines pour déployer sur n’importe laquelle d’entre elles. Laquelle devrions-nous essayer ?
Mara : Les équipes qui développent nos jeux se servent d’Azure pour héberger certains de leurs systèmes back-ends. Sa configuration est rapide et ils semblent en être satisfaits. Je pense que nous devrions nous en tenir à Azure pour notre cloud.
Andy : OK, c’est logique ! Mais Azure offre beaucoup d’options de calcul. Vers laquelle devons-nous porter notre choix ?
Andy liste ces options sur le tableau blanc :
- Machines virtuelles
- Conteneurs
- Azure App Service
- Informatique Serverless
Notes
Vous trouverez des informations supplémentaires sur chacune de ces options de calcul à la fin de ce module.
Mara : Je sais que les conteneurs et l’informatique Serverless ont le vent en poupe en ce moment. Par rapport aux machines virtuelles, ces deux options demandent peu de ressources. De plus, il est facile de les remplacer et d’en faire un scale-out. Les deux sont intéressantes, mais je suis anxieuse à l’idée de devoir assimiler deux nouvelles technologies à la fois. Je préfèrerais me concentrer sur la création du pipeline.
Andy : Je partage ton point de vue. Il reste les machines virtuelles et App Service. Je pense que les machines virtuelles sont un meilleur choix si nous devons déplacer dans le cloud une application métier qui nécessite un accès complet à un environnement particulier. Mais nous ne faisons rien de cette ampleur.
Mara : Il reste App Service, ce qui me semble être un bon choix. Ce service a été conçu pour fonctionner avec Azure DevOps et il offre des avantages. Il s’agit d’un environnement PaaS (platform as a service) pour les applications web, ce qui réduit fortement notre charge de travail. Nous n’avons pas à nous soucier de l’infrastructure. De plus, il intègre des fonctionnalités de sécurité et nous permet de procéder à un équilibrage de charge et à une mise à l’échelle automatique.
Andy : App Service répond bien à nos besoins. Partons sur App Service. De toute manière, nous créons simplement une preuve de concept. Nous serons toujours à temps de changer d’option de calcul si nous voulons par la suite essayer autre chose.
Comment Azure Pipelines gère-t-il les étapes de déploiement ?
Pour déployer votre application, Azure Pipelines doit d’abord s’authentifier auprès de l’environnement cible. Azure Pipelines propose différents mécanismes d’authentification. Votre choix dépend de l’environnement cible vers lequel vous effectuez le déploiement. Vous trouverez des informations supplémentaires sur ces mécanismes à la fin de ce module.
Andy : Nous disposons de notre artefact de build, et nous savons que nous générerons et déploierons dans les phases du pipeline. Nous avons aussi défini l’environnement cible de notre déploiement. C’est App Service. Maintenant, je m’interroge sur la façon dont Azure Pipelines s’authentifie auprès d’App Service ? Je sais que ce sera l’un des sujets de préoccupation de Tim. Nous devons vérifier que le processus est sécurisé.
Après quelques recherches, Andy et Mara trouvent la procédure générale de déploiement d’Azure Pipelines vers App Service, à savoir :
- Spécifier l’environnement de déploiement cible dans la configuration du pipeline.
- Trouver un moyen permettant à Azure Pipelines d’authentifier l’accès à cet environnement.
- Utiliser des tâches Azure Pipelines pour déployer l’artefact de build dans cet environnement.
Mara : D’après nos recherches, nous devons créer une connexion de service pour spécifier l’environnement cible et authentifier l’accès à celui-ci. Une fois que nous définissons la connexion de service, toutes nos tâches peuvent l’utiliser. Ensuite, nous devons utiliser les tâches intégrées DownloadPipelineArtifact pour télécharger l’artefact de build sur l’agent de pipeline et AzureWebApp pour déployer notre application sur Azure App Service.
En quoi consistent les travaux et les stratégies ?
Votre pipeline de build existant définit un agent de build, les variables du pipeline et les tâches nécessaires à la génération de votre logiciel.
La partie déploiement de votre pipeline contient ces mêmes éléments. La configuration de votre déploiement définit également un ou plusieurs travaux, un environnement de pipeline et des stratégies. Vous avez vu plus tôt en quoi consistent les environnements de pipeline.
Voici un exemple de configuration que vous exécuterez par la suite dans ce module. Cette configuration déploie le site web Space Game dans Azure App Service.
- stage: 'DeployDev'
displayName: 'Deploy to dev environment'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: 'Release Pipeline'
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
- task: AzureWebApp@1
displayName: 'Azure App Service Deploy: website'
inputs:
azureSubscription: 'Resource Manager - Tailspin - Space Game'
appName: '$(WebAppName)'
package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
travaux
Un travail est une série d’étapes—ou tâches—qui s’exécutent de manière séquentielle en tant qu’unité. Par défaut, chaque phase de pipeline se compose d’un travail, même quand elle n’utilise pas le mot clé job.
Un travail peut s’exécuter dans un pool d’agents, sur un conteneur ou directement sur le serveur Azure DevOps. L’exemple de travail illustré ici s’exécute sur un agent Ubuntu hébergé par Microsoft.
Vous pouvez spécifier les conditions d’exécution de chaque travail. L’exemple de travail illustré ici ne définit pas de conditions. Par défaut, un travail s’exécute s’il ne dépend d’aucun autre travail ou si tous les travaux dont il dépend ont bien abouti.
Vous pouvez également exécuter des travaux en parallèle ou de manière séquentielle. En utilisant votre pipeline de build existant comme exemple, vous pouvez utiliser des travaux parallèles pour générer vos logiciels simultanément sur des agents Windows, Linux et macOS.
Un travail de déploiement est un type de travail spécial qui joue un rôle important dans vos phases de déploiement. Les travaux de déploiement enregistrent l’état de vos déploiements dans Azure Pipelines, ce qui vous fait bénéficier d’une piste d’audit. Les travaux de déploiement vous aident également à définir votre stratégie de déploiement, ce que nous allons faire prochainement.
Stratégies
Une stratégie définit la façon dont votre application est déployée. Vous en apprendrez davantage sur les stratégies (par exemple, bleu-vert et avec contrôle de validité) dans un prochain module. Pour le moment, vous allez utiliser la stratégie runOnce pour télécharger le package Space Game à partir du pipeline et le déployer sur Azure App Service.
Comment Azure Pipelines se connecte-t-il à Azure ?
Pour déployer votre application dans une ressource Azure, par exemple une machine virtuelle ou App Service, vous avez besoin d’une connexion de service. Une connexion de service fournit un accès sécurisé à votre abonnement Azure en utilisant une des deux méthodes suivantes :
- Authentification d’un principal du service
- Identités managées pour les ressources Azure
Vous pouvez en apprendre davantage sur ces modèles de sécurité à la fin de ce module, mais en substance :
- Un principal de service est une identité ayant un rôle limité qui peut accéder aux ressources Azure. Le principal de service peut être considéré comme un compte de service capable d’effectuer des tâches automatisées pour votre compte.
- Les identités managées pour les ressources Azure sont une fonctionnalité de Microsoft Entra ID qui simplifie le processus d'utilisation des principaux de service. Étant donné que les identités managées existent sur le locataire Microsoft Entra, l'infrastructure Azure peut authentifier automatiquement le service et gérer le compte pour vous.
Les identités managées simplifient le processus de travail avec les principaux de service. Cependant, nous utilisons dans ce module l’authentification du principal de service, car une connexion de service peut découvrir automatiquement vos ressources Azure et attribuer pour vous les rôles de principal de service appropriés.
Le plan
Andy et Mara sont prêts à se lancer. Voici ce qu’ils vont faire :
- Partir de leur configuration de build Azure Pipelines existante.
- Définir une phase de build qui crée l’artefact.
- Définir une phase de déploiement qui déploie l’artefact dans App Service.
Andy : Ce dessin est-il correct ? Nous utilisons Azure Pipelines pour déployer sur Azure App Service. Pour ce faire, nous prenons l’artefact de build 
comme entrée de la phase de déploiement 
. Les tâches de la phase de déploiement téléchargent l’artefact 
et utilisent une connexion de service pour déployer l’artefact sur App Service 
.
Mara : C’est un bon résumé. Commençons.