Exercice - Promouvoir vers la phase de gestion intermédiaire
Votre pipeline de mise en production comporte désormais trois étapes : Build, Dev et Test. L’équipe Tailspin et vous-même avez une phase supplémentaire à implémenter : la gestion intermédiaire.
Dans cette partie, vous allez :
- Créez l'environnement intermédiaire dans Azure Pipelines et attribuez-vous le rôle d'approbateur.
- Définissez l’étape intermédiaire , qui s’exécute uniquement après qu’un approbateur vérifie les résultats de la phase de test .
Créer l’environnement intermédiaire
Dans cet exercice, vous créez un environnement dans Azure Pipelines pour la gestion intermédiaire. À des fins d’apprentissage, vous vous désignez vous-même comme approbateur. Dans la pratique, vous devez affecter les utilisateurs qui sont tenus d’approuver les modifications avant que ces modifications passent à la phase suivante. Pour l’équipe Tailspin, Amita approuve les changements pour qu’ils puissent être promus de la phase de test à la phase de gestion intermédiaire.
Plus haut dans ce module, vous avez spécifié environment
les paramètres des phases Dev et Test . Voici un exemple pour la phase de développement .
- stage: 'Deploy'
displayName: 'Deploy the web application'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: Release
Vous pouvez définir un environnement via Azure Pipelines qui inclut des critères spécifiques pour votre version. Ces critères peuvent inclure les pipelines autorisés à être déployés dans l’environnement. Vous pouvez également spécifier les approbations humaines nécessaires pour promouvoir la mise en production d’une étape à l’autre. Ici, vous spécifiez ces approbations.
Pour créer l’environnement staging :
Dans Azure Pipelines, sélectionnez Environnements.
Sélectionnez Nouvel environnement.
Sous Nom, entrez préproduction.
Laissez les champs restants à leurs valeurs par défaut.
Cliquez sur Créer.
Dans la page d’environnement intermédiaire , sélectionnez l’onglet Approbations et vérifications .
Sélectionnez Approbations.
Sous Approbateurs, sélectionnez Ajouter des utilisateurs et des groupes, puis sélectionnez votre compte.
Sous Instructions pour les approbateurs, entrez : Approuver cette modification quand elle est prête pour la mise en scène.
Cliquez sur Créer.
Promouvoir les changements vers la phase de gestion intermédiaire
Ici, vous modifiez votre configuration de pipeline pour déployer la build à l’étape intermédiaire .
Dans Visual Studio Code, modifiez azure-pipelines.yml comme suit :
trigger: - '*' variables: buildConfiguration: 'Release' releaseBranchName: 'release' schedules: - cron: '0 3 * * *' displayName: 'Deploy every day at 3 A.M.' branches: include: - release always: false stages: - stage: 'Build' displayName: 'Build the web application' jobs: - job: 'Build' displayName: 'Build job' pool: vmImage: 'ubuntu-20.04' demands: - npm variables: wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot' dotnetSdkVersion: '6.x' steps: - task: UseDotNet@2 displayName: 'Use .NET SDK $(dotnetSdkVersion)' inputs: version: '$(dotnetSdkVersion)' - task: Npm@1 displayName: 'Run npm install' inputs: verbose: false - script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)' displayName: 'Compile Sass assets' - task: gulp@1 displayName: 'Run gulp tasks' - script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt' displayName: 'Write build info' workingDirectory: $(wwwrootDir) - task: DotNetCoreCLI@2 displayName: 'Restore project dependencies' inputs: command: 'restore' projects: '**/*.csproj' - task: DotNetCoreCLI@2 displayName: 'Build the project - $(buildConfiguration)' inputs: command: 'build' arguments: '--no-restore --configuration $(buildConfiguration)' projects: '**/*.csproj' - task: DotNetCoreCLI@2 displayName: 'Publish the project - $(buildConfiguration)' inputs: command: 'publish' projects: '**/*.csproj' publishWebProjects: false arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)' zipAfterPublish: true - publish: '$(Build.ArtifactStagingDirectory)' artifact: drop - stage: 'Dev' displayName: 'Deploy to the dev environment' dependsOn: Build condition: | and ( succeeded(), eq(variables['Build.SourceBranchName'], variables['releaseBranchName']) ) jobs: - deployment: Deploy pool: vmImage: 'ubuntu-20.04' environment: dev variables: - group: Release 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: '$(WebAppNameDev)' package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip' - stage: 'Test' displayName: 'Deploy to the test environment' dependsOn: Dev #condition: eq(variables['Build.Reason'], 'Schedule') jobs: - deployment: Deploy pool: vmImage: 'ubuntu-20.04' environment: test variables: - group: 'Release' 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: '$(WebAppNameTest)' package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip' - stage: 'Staging' displayName: 'Deploy to the staging environment' dependsOn: Test jobs: - deployment: Deploy pool: vmImage: 'ubuntu-20.04' environment: staging variables: - group: 'Release' 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: '$(WebAppNameStaging)' package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
Ce code ajoute l’étape intermédiaire . Cette phase effectue le déploiement sur l’environnement intermédiaire, qui comprend une approbation de mise en production.
Conseil / Astuce
Vous avez probablement remarqué que les trois étapes de déploiement suivent des étapes similaires. Vous pouvez utiliser des modèles pour définir des tâches de génération courantes une seule fois et les réutiliser plusieurs fois. Vous avez déjà utilisé cette technique dans le module Créer un pipeline de build avec le module Azure Pipelines . À des fins d’apprentissage, nous répétons les étapes de chaque étape.
À partir du terminal intégré, ajoutez azure-pipelines.yml à l’index. Ensuite, validez la modification et envoyez-la à GitHub.
Conseil / Astuce
Avant d’exécuter ces commandes Git, enregistrez azure-pipelines.yml.
git add azure-pipelines.yml git commit -m "Deploy to Staging" git push origin release
Dans Azure Pipelines, accédez à la build. Suivez la build pendant son exécution.
Quand la build arrive en gestion intermédiaire, vous constatez que le pipeline attend que toutes les vérifications réussissent. Dans le cas présent, nous avons une seule vérification : l’approbation de mise en production manuelle.
Vous pouvez configurer Azure DevOps pour vous envoyer une notification par e-mail lorsque la build nécessite une approbation. Voici un exemple :
Sélectionnez Vérifier>Approuver.
Dans la pratique, pour vérifier qu’ils répondent à vos besoins, vous examinerez les modifications.
Une fois la build terminée, ouvrez un navigateur web. Accédez à l’URL associée à l’instance d’App Service de votre environnement intermédiaire.
Si l’onglet du navigateur est toujours ouvert, actualisez la page. Si vous ne vous souvenez pas de l’URL, recherchez-la dans le portail Azure, dans la page de détails d’App Service .
Vous voyez que le site web Space Game est déployé sur App Service et est en cours d’exécution.
En guise d’étape facultative, dans Azure Pipelines, sélectionnez Environnements. Ensuite, sélectionnez l’environnement d'essai.
Azure Pipelines enregistre votre historique de déploiement, ce qui vous permet de tracer les modifications dans l’environnement en retour aux validations de code et aux éléments de travail.
L’équipe Tailspin se réunit pour discuter de leur progression. Amita approuve les changements dans la phase de test tandis que les autres regardent.
Tim: Pour vous dire la vérité, au début, j’étais un peu nerveux au sujet des pipelines de mise en production automatisés. Mais j’aime vraiment ça maintenant que je vois ça fonctionner. Chaque étape peut avoir son propre environnement, les tests associés et les approbateurs. Le pipeline automatise de nombreuses choses que nous avons dû faire manuellement. Mais nous avons toujours le contrôle où nous en avons besoin.
Amita: Je pourrais nous imaginer en train de faire quelque chose de similaire pour promouvoir les changements de la mise en scène à la production. D’ailleurs, quand allons-nous ajouter un environnement de production ?
Andy: Bientôt. Je pense que nous devons encore compléter quelques éléments ici avant d’ajouter cela.