Exercício - Promover para a fase de Teste

8 minutos

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 .

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.

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
```
No Azure Pipelines, vá para a compilação. Rastreie a compilação enquanto ela é executada.
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.
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.
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.

Continuar

Exercício - Promover para a fase de Teste

Promover alterações na etapa de teste

Comentários