Exercício - Promover para a fase de Teste
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:
ymltrigger: - '*' 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. Oalways
sinalizador é definido parafalse
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 éSchedule
igual a . (A variávelBuild.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.
Bashgit 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.