Visualizar e aprovar a implantação

5 minutos

Agora você aprendeu sobre trabalhos de fluxo de trabalho e como adicionar um trabalho de fluxo de trabalho para validar o código Bicep. A próxima etapa para ter confiança em sua implantação é adicionar outro trabalho a fim de verificar exatamente o que será mudado por ela.

Nesta unidade, você aprenderá a usar o comando de teste de hipóteses em um fluxo de trabalho. Também aprenderá a adicionar regras de proteção de ambiente para poder verificar manualmente a saída do comando antes da execução da implantação.

A operação de teste de hipóteses

Um arquivo Bicep descreve o estado em que você deseja que o ambiente do Azure esteja no final de uma implantação. Quando você envia uma implantação, o Azure Resource Manager altera seu ambiente do Azure para corresponder ao estado descrito no seu arquivo Bicep.

Uma implantação pode resultar na implantação de novos recursos no ambiente ou na atualização de recursos existentes. Quando você executa uma implantação no modo completo, pode acabar excluindo recursos existentes.

Sempre que recursos são criados, atualizados ou excluídos, há o risco de que as coisas mudem de uma forma que você não esperava. É uma boa prática adicionar uma etapa extra para verificar o que será exatamente criado, atualizado e excluído. Esta verificação agrega valor ao processo de automação. Quando estiver implantando em um ambiente de produção, é importante confirmar todas as alterações que ocorrem no seu ambiente.

O Resource Manager fornece a operação de teste de hipóteses, que pode ser executada no arquivo Bicep dentro do trabalho do fluxo de trabalho:

Diagrama de um fluxo de trabalho que inclui os trabalhos Lint, Validar e Visualizar. O trabalho Visualizar executa uma operação de teste de hipóteses no Azure.

A ação arm-deploy dá suporte ao acionamento da operação de teste de hipóteses (what-if) usando a propriedade additionalArguments:

jobs:
  preview:
     runs-on: ubuntu-latest
     needs: [lint, validate]
     steps: 
     - uses: azure/login@v1
       name: Sign in to Azure
       with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
     - uses: azure/arm-deploy@v1
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
         template: deploy/main.bicep
         parameters: >
           environmentType=${{ env.ENVIRONMENT_TYPE }}
         additionalArguments: --what-if

O código realçado é equivalente à execução da implantação usando a CLI do Azure, com o argumento --what-if incluído.

A operação de teste de hipóteses não faz nenhuma alteração no ambiente. Ele descreve os recursos que serão criados, as propriedades dos recursos que serão atualizadas e os recursos que serão excluídos.

Às vezes, o teste de hipóteses mostra que um recurso mudará quando, na verdade, nenhuma mudança acontecerá. Esse tipo de saída é chamado de ruído. Estamos trabalhando para reduzir esses problemas, mas precisamos da sua ajuda. Relate problemas de teste de hipóteses.

Depois de ver a saída da operação de teste de hipóteses, determine se deseja continuar com a implantação. Essa etapa normalmente envolve uma análise humana da saída do comando de teste de hipóteses e, depois, a tomada de decisão sobre se as alterações identificadas são razoáveis. Se um revisor humano decidir que as alterações são razoáveis, ele poderá aprovar manualmente a execução do fluxo de trabalho.

Para saber mais sobre o comando de teste de hipóteses, confira o módulo Visualizar as alterações de implantação do Azure usando o teste de hipóteses do Microsoft Learn.

Ambientes

No GitHub Actions, um ambiente representa o local no qual sua solução é implantada. Os ambientes fornecem recursos que ajudam quando você trabalha com implantações complexas. Em um módulo posterior, você aprenderá mais sobre os ambientes e os respectivos recursos. Por enquanto, vamos nos concentrar em sua capacidade de adicionar revisores necessários ao seu fluxo de trabalho.

Você cria um ambiente usando a interface da Web do GitHub. Você pode criar ambientes ao trabalhar com um repositório GitHub público ou ao usar uma conta do GitHub Enterprise.

Após criar um ambiente, você pode referenciar ele em qualquer trabalho no fluxo de trabalho:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: 'Lint Bicep template'
      run: az bicep build --file deploy/main.bicep

  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
        deploymentMode: Validate

  deploy:
    runs-on: ubuntu-latest
    environment: MyAzureEnvironment
    needs: [lint, validate]
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Observação

Quando a identidade da carga de trabalho do seu fluxo de trabalho de implantação interage com o Resource Manager em um ambiente, ela precisa de uma credencial federada que esteja configurada com o nome do ambiente. Você aprenderá mais sobre ambientes em módulos futuros. Ao executar os exercícios desse módulo, você criará as credenciais federadas necessárias.

Regras de proteção do ambiente

Depois de criar um ambiente, você pode definir regras de proteção. As regras de proteção são usadas para verificar as condições que devem ser atendidas para que uma etapa use o ambiente. A regra de proteção de revisor necessário é um tipo de verificação que requer que uma pessoa forneça uma aprovação manual.

As regras de proteção são definidas no ambiente, não no fluxo de trabalho. Os autores do arquivo YAML do fluxo de trabalho não podem remover ou adicionar essas regras de proteção. Apenas os administradores de um repositório ou o proprietário da conta podem gerenciar ambientes e suas regras de proteção.

As regras de proteção do ambiente ajudam a garantir que as pessoas certas estejam envolvidas no processo de implantação.

Como funcionam as regras de proteção do ambiente?

Quando você associa um ambiente a uma etapa, as regras de proteção do ambiente são avaliadas antes do início dela.

A necessidade de um revisador é um tipo de regra de proteção. Ao configurar uma regra de proteção de revisor necessário, você atribui um ou mais usuários do GitHub que precisam aprovar a continuação do fluxo de trabalho.

Os ambientes também fornecem outros tipos de regras de proteção. Por exemplo, você pode restringir os branches Git que podem ser implantados em ambientes específicos. Este módulo discute somente a regra de revisor necessário, mas serão fornecidos links para mais informações sobre outras regras de proteção no resumo.

Depois que o fluxo de trabalho começa e inicia uma etapa que requer um revisor, sua execução é interrompida. Todos os usuários que são designados como revisores recebem uma mensagem no GitHub e por email.

Os revisores podem inspecionar os logs do fluxo de trabalho, como as alterações detectadas pela operação de teste de hipóteses. Com base nessas informações, eles aprovam ou rejeitam a alteração. No caso de aprovação, o fluxo de trabalho é retomado. No caso de rejeição ou resposta fora do período de tempo limite, o trabalho falha.

Diagrama de um fluxo de trabalho que inclui os trabalhos Lint, Validar, Visualizar e Implantar, com uma verificação de aprovação antes do trabalho Implantar.

A importância de boas práticas

O recurso de ambientes no GitHub oferece a capacidade de vincular implantações a um ambiente, que herdarão as regras de proteção definidas pelo administrador desse ambiente. No entanto, não há nada que exija que novos fluxos de trabalho usem ambientes.

É importante que sua organização estabeleça boas práticas para examinar suas definições de fluxo de trabalho. Por exemplo, configure seu repositório para exigir revisões da solicitação de pull em qualquer alteração em sua ramificação principal utilizando regras de proteção de ramificação. Você aprenderá mais sobre esse conceito em um próximo módulo.