Ler em inglês

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:

    yml
    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.

    Bash
    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.

    A screenshot of Azure Pipelines showing three completed stages: Build, Dev, and Test.

    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.

    A screenshot of a web browser showing the Space Game website in the Test environment.

  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.

    A screenshot of Azure Pipelines showing the deployment history. The history shows one successful deployment.

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.