Exercício - Promover para a fase de Teste

Concluído

Seu pipeline de lançamento ainda tem dois estágios, mas agora eles são diferentes do que antes. As etapas são Build e Dev. Cada alteração enviada por push para o GitHub aciona o estágio Build para ser executado. O estágio de desenvolvimento é executado somente quando a alteração está na ramificação de versão . Aqui, você adiciona o estágio de teste ao pipeline.

Lembre-se de que a equipe decidiu usar um gatilho programado para promover a compilação do estágio de Desenvolvimento para o estágio de Teste às 3 da manhã todas as manhãs. Para configurar o gatilho agendado:

• Defina o cronograma em sua configuração de compilação.
• Defina o estágio de teste, que inclui uma condição que executa o estágio somente se o motivo da compilação estiver marcado como Schedule.

Para fins de aprendizagem, aqui, você define o cronograma, mas permite que a compilação vá diretamente do desenvolvedor para o teste. Essa configuração evita a necessidade de esperar que o agendamento seja acionado. Depois de concluir este módulo, tente experimentar diferentes expressões cron para executar o estágio de teste somente no horário agendado.

Promover alterações na etapa de teste

Aqui, você modifica sua configuração de pipeline para implantar a compilação no estágio de teste .

1. No Visual Studio Code, modifique azure-pipelines.yml da seguinte maneira:

   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'
   

   A schedules seção define uma expressão cron. Você pode definir mais de uma expressão em sua configuração. A expressão aciona o pipeline para ser executado contra a ramificação de liberação às 3 da manhã todos os dias. O always sinalizador é definido para false que o pipeline seja executado somente quando a ramificação de liberação contiver alterações da execução anterior.

   O Test estágio define uma condição que executa o estágio somente quando o motivo da compilação é Scheduleigual a . (A variável Build.Reason interna define o motivo da compilação.) Se essa condição for falsa, o estágio será ignorado, mas os estágios anteriores continuarão a ser executados.

   Nota

   Esta condição é mostrada para fins de aprendizagem. É comentado para permitir que a mudança passe de Dev para Test sem esperar que o agendamento seja acionado.

2. Do terminal integrado ao índice, adicione azure-pipelines.yml. Em seguida, confirme a alteração e envie-a para o GitHub.

   Gorjeta

   Antes de executar esses comandos do Git, salve azure-pipelines.yml.

   git add azure-pipelines.yml
   git commit -m "Deploy to the Test stage"
   git push origin release
   

3. No Azure Pipelines, vá para a compilação. Rastreie a compilação enquanto ela é executada.

4. Após a conclusão da compilação, para retornar à página de resumo, selecione o botão Voltar.

   

   Você vê que a implantação foi concluída com êxito.

5. Em um navegador da Web, vá para a URL associada à instância do Serviço de Aplicativo para seu ambiente de teste .

   Se você ainda tiver a guia do navegador aberta, atualize a página. Se não se lembrar do URL, encontre-o no portal do Azure, na página de detalhes do Serviço de Aplicativo.

   Você vê que o site do Jogo Espacial está implantado no Serviço de Aplicativo e está em execução.

   

6. Como etapa opcional, no Azure Pipelines, selecione Ambientes. Em seguida, selecione o ambiente de teste .

   O Azure Pipelines registra seu histórico de implantação. No histórico, você pode rastrear alterações no ambiente de volta para confirmações de código e itens de trabalho.

   

Andy e Mara adicionam o estágio de teste ao pipeline. Eles mostram os resultados para Amita.

Amita: Eu gosto que as mudanças sejam construídas e implantadas para que eu possa testá-las todas as manhãs. Mas não vejo como posso controlar quando as mudanças chegam ao Staging.

Mara: Sim, a implantação por meio da automação economiza muito tempo. Lembre-se de que incluímos apenas o gatilho agendado. Vamos adicionar uma aprovação de versão para você quando configurarmos o ambiente de preparo para Tim. Dessa forma, as alterações passam para Preparação somente quando você estiver pronto.