Visualizar e aprovar sua implantação

5 minutos

Agora você aprendeu sobre trabalhos de fluxo de trabalho e como pode adicionar um trabalho de fluxo de trabalho para validar seu código Bicep. A próxima etapa para criar confiança com sua implantação é adicionar outro trabalho para verificar exatamente o que sua implantação mudará.

Nesta unidade, você aprenderá sobre como usar o comando what-if em um fluxo de trabalho. Você também aprenderá sobre como adicionar regras de proteção de ambiente para ter a oportunidade de verificar manualmente a saída do comando antes que a implantação seja executada.

A operação hipotética

Um arquivo Bicep descreve o estado em que você deseja que seu 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 em seu arquivo Bicep.

Uma implantação pode resultar na implantação de novos recursos em seu ambiente ou na atualização de recursos existentes. Quando você executa uma implantação no modo completo, isso pode até resultar na exclusão de recursos existentes.

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

O Resource Manager fornece a operação hipotética, que você pode executar em seu arquivo Bicep dentro de seu trabalho de fluxo de trabalho:

Diagrama de um fluxo de trabalho que inclui trabalhos Lint, Validar e Visualizar. O trabalho de visualização executa uma operação hipotética no Azure.

A arm-deploy ação oferece suporte ao acionamento da operação hipotética usando a additionalArguments propriedade:

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 a executar a implantação usando a CLI do Azure, com o --what-if argumento incluído.

A operação hipotética não faz alterações no seu ambiente. Em vez disso, ele descreve os recursos que serão criados, as propriedades do recurso que serão atualizadas e os recursos que serão excluídos.

E se, às vezes, mostra que um recurso mudará quando, na verdade, nenhuma mudança acontecerá. Este tipo de saída é chamado de ruído. Estamos a trabalhar para reduzir estes problemas, mas precisamos da sua ajuda. Denuncie problemas hipotéticos.

Depois de ver a saída da operação hipotética, você pode determinar se deve continuar para a implantação. Esta etapa normalmente envolve um ser humano revisando a saída do comando what-if e, em seguida, tomando uma 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 what-if, consulte o módulo Microsoft Learn Preview Azure deployment changes by using what-if.

Ambientes

Em Ações do GitHub, um ambiente representa o local onde sua solução é implantada. Os ambientes fornecem recursos que ajudam quando você trabalha com implantações complexas. Em um módulo futuro, você aprenderá mais sobre ambientes e seus recursos. Por enquanto, nos concentramos na capacidade deles de adicionar os revisores necessários ao seu fluxo de trabalho.

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

Depois de criar um ambiente, você pode fazer referência a ele em qualquer trabalho em seu 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 }}

Nota

Quando a identidade da carga de trabalho do fluxo de trabalho de implantação interage com o Resource Manager em um ambiente, ele precisa de uma credencial federada configurada com o nome do ambiente. Você aprenderá mais sobre ambientes em módulos futuros. Ao executar os exercícios para este 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 antes que uma etapa possa usar o ambiente. A regra de proteção de revisores necessária é um tipo de verificação que requer que um ser humano 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. Somente 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 ambiental ajudam a garantir a participação das pessoas certas 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 pouco antes do início da etapa.

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

Os ambientes também oferecem outros tipos de regras de proteção. Por exemplo, você pode restringir as ramificações do Git que podem ser implantadas em ambientes específicos. Discutimos apenas a regra de revisores necessária neste módulo, mas fornecemos links para mais informações sobre outras regras de proteção no resumo.

Depois que o fluxo de trabalho começa e atinge uma etapa que requer um revisor, a execução do fluxo de trabalho é pausada. Todos os usuários designados como revisores recebem uma mensagem no GitHub e por e-mail.

Os revisores podem inspecionar os logs de fluxo de trabalho, como as alterações detetadas pela operação hipotética. Com base nessas informações, eles aprovam ou rejeitam a alteração. Se eles aprovarem a alteração, o fluxo de trabalho será retomado. Se eles rejeitarem, ou se não responderem dentro do período de tempo limite, o trabalho falhará.

Diagrama de um fluxo de trabalho que inclui trabalhos Lint, Validate, Preview, e Deploy, com uma verificação de aprovação antes do trabalho Deploy.

A importância das boas práticas

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

É importante que uma organização estabeleça boas práticas para rever as definições do seu fluxo de trabalho. Por exemplo, configure seu repositório para exigir revisões de solicitação pull em quaisquer alterações na ramificação principal usando regras de proteção de ramificação. Você aprenderá mais sobre esse conceito em um módulo futuro.