Exercice - Promouvoir vers la phase de test

8 minutes

Votre pipeline de mise en production comporte toujours deux phases, mais ils sont maintenant différents de ceux précédents. Les phases sont Build et Dev. Chaque modification que vous envoyez (push) à GitHub déclenche l’exécution de l’étape de génération . La phase de développement s’exécute uniquement lorsque la modification se trouve dans la branche de mise en production . Ici, vous ajoutez la phase de test au pipeline.

Rappelez-vous que l’équipe a décidé d’utiliser un déclencheur planifié pour promouvoir la build de la phase de développement à l’étape de test à 3 A.M. chaque matin. Pour configurer le déclencheur planifié :

Définissez la planification dans votre configuration de build.
Définissez la phase de test , qui inclut une condition qui exécute l’étape uniquement si la raison de build est marquée comme Schedule.

À des fins d’apprentissage, ici, vous définissez la planification, mais autorisez la génération à passer directement de Dev à Test. Cette configuration évite la nécessité d'attendre l'activation du programme. Une fois ce module terminé, essayez d’expérimenter différentes expressions cron pour exécuter la phase de test uniquement à l’heure planifiée.

Promouvoir les modifications apportées à la phase de test

Ici, vous modifiez la configuration de votre pipeline pour déployer la build dans la phase de test .

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'

La schedules section définit une expression cron. Vous pouvez définir plusieurs expressions dans votre configuration. L’expression déclenche l’exécution du pipeline sur la branche de mise en production à 3h00 chaque jour. L’indicateur always est défini false pour que le pipeline s’exécute uniquement lorsque la branche de publication contient des modifications depuis la dernière exécution.

L’étape Test définit une condition qui exécute l’étape uniquement lorsque la raison de build est égale Schedule. (La variable Build.Reason intégrée définit la raison de build.) Si cette condition est false, l’étape est ignorée, mais les étapes précédentes continuent à s’exécuter.

Remarque

Cette condition est montrée à des fins d’apprentissage. Elle est mise en commentaire pour que le changement puisse passer de la phase de développement à la phase de test sans attendre le déclenchement de la planification.

À partir du terminal intégré, à l’index, ajoutez azure-pipelines.yml. Ensuite, validez la modification et poussez-la vers GitHub.

Conseil / Astuce

Avant d’exécuter ces commandes Git, enregistrez azure-pipelines.yml.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Test stage"
git push origin release
```
Dans Azure Pipelines, accédez à la build. Suivez la build pendant son exécution.
Une fois la construction terminée, pour revenir à la page récapitulative, sélectionnez le bouton précédent.

Vous voyez que le déploiement s’est terminé correctement.
À partir d’un navigateur web, accédez à l’URL associée à l’instance App Service pour votre environnement de test .

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 qu’il est en cours d’exécution.
En guise d’étape facultative, dans Azure Pipelines, sélectionnez Environnements. Sélectionnez ensuite l’environnement de test .

Azure Pipelines enregistre votre historique de déploiement. Dans l'historique, vous pouvez suivre les changements dans l'environnement jusqu'aux validations de code et aux éléments de travail.

Andy et Mara ajoutent la phase de test au pipeline. Ils montrent les résultats à Amita.

Amita: J’aime que les modifications soient générées et déployées afin que je puisse les tester chaque matin. Mais je ne vois pas comment je peux contrôler quand les modifications arrivent dans l'environnement de test.

Mara: Oui, le déploiement par le biais de l’automatisation permet de gagner beaucoup de temps. N’oubliez pas que nous avons inclus uniquement le déclencheur planifié. Ajoutons une approbation de mise en production quand nous configurons l’environnement de préproduction pour Tim. De cette façon, les modifications passent à Staging uniquement lorsque vous êtes prêt.

Commentaires

Cette page a-t-elle été utile ?