Exercício – Promover para a fase de Desenvolvimento

8 minutos

A equipe tem um plano e está pronta para começar a implementar o pipeline de lançamento. Seu projeto do Azure DevOps está configurado e suas instâncias do Serviço de Aplicativo do Azure estão prontas para receber artefatos de compilação.

Neste ponto, lembre-se de que o pipeline da equipe tem somente duas fases. A primeira fase produz o artefato de compilação. A segunda fase implanta o aplicativo Web Space Game no Serviço de Aplicativo. Aqui, você acompanha Paulo e Clara conforme eles modificam o pipeline. Eles serão implantados no ambiente do Serviço de Aplicativo que corresponde à fase de Desenvolvimento.

A fase de Desenvolvimento é semelhante à fase de implantação realizada no módulo Create a release pipeline in Azure Pipelines. Lá, você usou um gatilho de CI para iniciar o processo de build. Aqui você fará o mesmo.

Buscar o branch do GitHub

Aqui, você efetuará fetch do branch release do GitHub. Você também faz check-out ou alterna para o branch.

Esse branch serve como seu branch de lançamento. Ele contém o projeto do Space Game usado nos módulos anteriores. Ele também contém uma configuração do Azure Pipelines com a qual começar.

Para efetuar fetch e alternar para o branch:

No Visual Studio Code, abra o terminal integrado.
Para efetuar fetch de um branch chamado release do repositório da Microsoft e alternar para ele, execute os comandos git a seguir.
```
git fetch upstream release
git checkout -B release upstream/release
```
O formato desses comandos permite que você obtenha o código inicial do repositório GitHub da Microsoft, conhecido como upstream. Em breve, você efetuará push desse branch para seu repositório do GitHub, conhecido como origin.
Como uma etapa opcional, no Visual Studio Code, abra azure-pipelines.yml. Familiarize-se com a configuração inicial.

A configuração é semelhante à básica criada no módulo Create a release pipeline in Azure Pipelines. Ela compila apenas a configuração da versão do aplicativo. Para fins de aprendizado, essa configuração não executa as verificações de segurança nem de qualidade que você configurou nos módulos anteriores.

Observação

Uma configuração mais robusta pode especificar os branches que participam do processo de build. Por exemplo, para ajudar a verificar a qualidade do código, você pode executar testes de unidade cada vez que efetuar push de uma alteração em qualquer branch. Você também pode implantar o aplicativo em um ambiente que executa testes mais exaustivos. Porém, realize essa implantação somente quando você tiver uma solicitação de pull, uma versão Release Candidate ou quando mesclar o código com o principal.

Para obter mais informações, confira Implement a code workflow in your build pipeline by using Git and GitHub e Gatilhos de pipeline de build.

Promover alterações para a fase de Desenvolvimento

Aqui, você modifica a configuração do pipeline para promover o build para a fase de Desenvolvimento.

No Visual Studio Code, modifique azure-pipelines.yml.

trigger:
- '*'

variables:
  buildConfiguration: 'Release'
  releaseBranchName: 'release'

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'

A configuração é semelhante à que você criou no módulo anterior. Nele, você e a equipe criaram uma prova de conceito para implantação contínua. Mas observe as diferenças realçadas no exemplo de código anterior:

Essa configuração define variáveis no início do arquivo. As variáveis são usadas em todo o pipeline. Elas definem qual configuração deve ser compilada (Release). Também definem o nome de seu branch de lançamento (release).
A fase de Implantação da prova de conceito agora se chama Desenvolvimento.
A fase de Desenvolvimento usa uma condição que instrui o sistema a executar a fase somente quando a fase anterior tiver sido bem-sucedida e o branch atual for release. Essa configuração garante que os recursos da versão sejam implantados somente no ambiente de Desenvolvimento.
A etapa de implantação usa a variável WebAppNameDev para implantar a instância do Serviço de Aplicativo associada ao ambiente de Desenvolvimento.

Observação

Na prática, você pode implantar de algum outro branch, como main. Você pode incluir lógica que permita que os branches sejam promovidos para a fase de Desenvolvimento de vários branches, como release e main.

No terminal integrado, adicione azure-pipelines.yml ao índice. Faça commit da alteração e efetue push dela para o GitHub.

Dica

Antes de executar esses comandos Git, salve azure-pipelines.yml.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Dev stage"
git push origin release
```
No Azure Pipelines, acesse o build. Enquanto ela é executada, faça o rastreamento do build.
Depois de terminar o build, para retornar à página de resumo, selecione o botão Voltar.

Você verá 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 de seu ambiente de Desenvolvimento.

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

Você verá que o site do Space Game está implantado no Serviço de Aplicativo e está em execução.
Como uma etapa opcional, no Azure Pipelines, selecione Environments. Em seguida, selecione o ambiente de desenvolvimento.

O Azure Pipelines registra seu histórico de implantação. Nele, você pode rastrear as alterações do ambiente até as confirmações de código e os itens de trabalho.

Exercício – Promover para a fase de Desenvolvimento

Buscar o branch do GitHub

Promover alterações para a fase de Desenvolvimento

Comentários