Exercice - Promouvoir vers la phase de préproduction

8 minutes

Votre pipeline de mise en production comporte désormais trois phases : génération, développement et test. L’équipe Tailspin et vous-même avez une phase supplémentaire à implémenter : la préproduction.

Dans cette partie, vous allez :

Créer l’environnement de préproduction dans Azure Pipelines et vous attribuer le rôle d’approbateur
Définir la phase de préproduction, qui s’exécute uniquement après vérification des résultats de la phase de test par un approbateur.

Créer l’environnement de préproduction

Dans cet exercice, vous allez créer un environnement de préproduction dans Azure Pipelines. Pour les besoins de cette formation, vous allez vous attribuer le rôle d’approbateur. En pratique, vous attribueriez les utilisateurs chargés d’approuver les changements avant que ceux-ci ne 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 préproduction.

Précédemment dans ce module, vous avez spécifié des paramètres environment pour les phases de développement et de 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 dans Azure Pipelines un environnement qui comprend des critères spécifiques pour votre mise en production. Ces critères peuvent inclure les pipelines autorisés à effectuer un déploiement sur l’environnement. Vous pouvez également spécifier les approbations humaines nécessaires pour promouvoir la mise en production d’une phase à la suivante. Ici, vous allez spécifier ces approbations.

Pour créer l’environnement de préproduction :

Dans Azure Pipelines, sélectionnez Environnements.
Sélectionnez Nouvel environnement.
Sous Nom, entrez préproduction.
Laissez les valeurs par défaut dans les champs restants.
Sélectionnez Créer.
Dans la page de l’environnement préproduction, ouvrez la liste déroulante, puis sélectionnez Approbations et vérifications.
Sélectionnez Approbations.
Sous Approbateurs, sélectionnez Ajouter des utilisateurs et des groupes, puis sélectionnez votre compte.
Sous Instructions destinées aux approbateurs, entrez Approuver ce changement quand il est prêt pour la préproduction.
Sélectionnez Créer.

Promouvoir les changements en préproduction

Dans cet exercice, vous modifiez la configuration de votre pipeline pour déployer la build dans la phase de développement.

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 la phase Staging (Préproduction). Cette phase déploie la build sur l’environnement de préproduction, qui comprend une approbation de mise en production.

Conseil

Vous avez probablement remarqué que vos trois phases de déploiement suivent des étapes similaires. Vous pouvez utiliser des modèles pour définir une seule fois des tâches de génération courantes que vous pourrez réutiliser plusieurs fois. Vous avez déjà utilisé cette technique dans le module Créer un pipeline de build avec Azure Pipelines. Pour les besoins de cette formation, nous répétons les phases pour chaque phase.

À partir du terminal intégré, ajoutez azure-pipelines.yml à l’index. Validez ensuite le changement et poussez-le vers GitHub.

Conseil

Enregistrez azure-pipelines.yml avant d’exécuter ces commandes Git.
```
git add azure-pipelines.yml
git commit -m "Deploy to Staging"
git push origin release
```
Dans Azure Pipelines, accédez à la build. Suivez l’exécution de la build.

Quand la build arrive en préproduction, 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 quand la build nécessite une approbation. Voici un exemple :
Sélectionnez Revue>Approuver.

Dans la pratique, vous examineriez les changements pour vérifier qu’ils respectent vos exigences.
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, sur la page des détails App Service.

Vous voyez que le site web Space Game est déployé sur App Service et qu’il est en cours d’exécution.
Si vous le souhaitez, dans Azure Pipelines, sélectionnez Environnements. Ensuite, sélectionnez l’environnement préproduction.

Azure Pipelines enregistre votre historique de déploiement. Celui-ci vous permet de retracer les changements de l’environnement jusqu’aux validations de code et aux éléments de travail.

L’équipe Tailspin se réunit pour parler de sa progression. Amita approuve les changements à la phase de test pendant que les autres regardent.

Tim : Pour vous dire la vérité, l’idée d’utiliser des pipelines de mise en production automatisés m’inquiétait un peu au début. Mais à présent, je vois tout cela fonctionner et je suis ravi. Chaque phase peut avoir son propre environnement, ses tests associés et ses approbateurs. Le pipeline automatise de nombreuses tâches que nous devions effectuer manuellement auparavant. Mais nous avons toujours le contrôle si nécessaire.

Amita : Je nous imagine procéder de façon similaire pour promouvoir les changements de l’environnement de préproduction à l’environnement de production. D’ailleurs, quand allons-nous ajouter un environnement de production ?

Andy : Sous peu. Je pense qu’il nous reste encore quelques ajustements à effectuer avant d’ajouter cela.

Exercice - Promouvoir vers la phase de préproduction

Créer l’environnement de préproduction

Promouvoir les changements en préproduction

Commentaires