Visualizar e aprovar a implantação

Você já aprendeu sobre as fases do pipeline e como adicionar uma fase de pipeline para validar o código do Bicep. A próxima etapa para aumentar sua confiança na implantação será adicionar outra fase para verificar exatamente o que será alterado pela implantação.

Nesta unidade, você aprenderá a usar o comando what-if em um pipeline. Você também aprenderá a adicionar aprovações para que tenha a oportunidade de verificar manualmente a saída do comando antes da implantação ser executada.

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 que ele corresponda ao estado descrito no arquivo Bicep.

Uma implantação pode resultar em novos recursos sendo implantados em seu ambiente ou recursos existentes sendo atualizados. Quando você executa uma implantação no modo completo, pode acabar excluindo recursos existentes.

Quando os recursos são criados, atualizados ou excluídos, há um risco de que as coisas possam mudar de uma maneira que você não espera. É uma boa prática adicionar uma etapa extra para verificar que recursos serão criados, atualizados e excluídos. Esta verificação agrega valor ao processo de automação. No caso de implantações em um ambiente de produção, é muito importante confirmar todas as alterações que acontecerão no ambiente.

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

Você pode usar o comando az deployment group what-if da CLI do Azure na definição do pipeline para executar a etapa de teste de hipóteses:

stages:

- stage: Preview
  jobs: 
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

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á. Esses comentários são chamados ruído. Estamos trabalhando para reduzir esses problemas. Você pode relatar problemas aqui.

Depois de ver o resultado da operação what-if, você pode determinar se deseja continuar com a implantação. Essa etapa normalmente envolve um 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 decidir que as alterações são razoáveis, ele poderá aprovar manualmente a execução do pipeline.

Ambientes

No Azure Pipelines, um ambiente representa o local para o 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, nosso foco será a capacidade deles de adicionar aprovações manuais ao pipeline.

Como você já sabe, use trabalhos para definir uma sequência de etapas dentro de uma fase do pipeline. Ao incluir ambientes em seu pipeline, você precisa usar um tipo especial de trabalho chamado de trabalho de implantação. Um trabalho de implantação é semelhante a um trabalho normal, mas fornece algumas funcionalidades extras. Essa funcionalidade inclui a definição do ambiente que o trabalho de implantação usa:

variables:
  - name: deploymentDefaultLocation
    value: westus3

stages:

- stage: Preview
  jobs:
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

- stage: Deploy
  jobs:
    - deployment: Deploy
      environment: MyAzureEnvironment
      strategy:
        runOnce:
          deploy:
            steps:
            - checkout: self

            - task: AzureResourceManagerTemplateDeployment@3
              name: Deploy
              displayName: Deploy to Azure
              inputs:
                connectedServiceName: 'MyServiceConnection'
                location: $(deploymentDefaultLocation)
                resourceGroupName: $(ResourceGroupName)
                csmFile: deploy/main.bicep

Observe que, na definição yaml para um trabalho de implantação, há algumas diferenças importantes em relação a um trabalho normal:

• Em vez de começar com a palavra job, um trabalho de implantação é definido como uma deployment.
• A palavra-chave environment especifica o nome do ambiente como o destino. No exemplo anterior, a implantação é acompanhada em um ambiente chamado MyAzureEnvironment.
• A palavra-chave strategy especifica como o Azure Pipelines executa as etapas de implantação. As estratégias de implantação dão suporte a processos de implantação complexos, especialmente quando você tem vários ambientes de produção. Neste módulo, você usa a runOnce estratégia de implantação. Essa estratégia se comporta da mesma forma que os outros trabalhos com os que você já está acostumado.

Verificações e aprovações de fases

Depois de criar um ambiente, você pode definir verificações. As verificações são usadas para verificar as condições que precisam ser atendidas para que um pipeline use o ambiente. Uma aprovação é um tipo de verificação que requer que um humano forneça uma aprovação manual.

As verificações são definidas no ambiente, não no pipeline. Os autores do arquivo YAML do pipeline não podem remover nem adicionar essas verificações e aprovações. Somente os administradores de um ambiente podem gerenciar as aprovações e as verificações nele.

Em muitas organizações, o proprietário de um ambiente no Azure Pipelines é a pessoa responsável pelo ambiente em que ele implanta. Verificações e aprovações ajudam a garantir que as pessoas certas estejam envolvidas no processo de implantação.

Como funcionam as verificações e as aprovações?

As aprovações e verificações são avaliadas logo antes do início de uma fase do pipeline. Quando o Azure Pipelines está prestes a executar um estágio de pipeline, ele analisa todos os recursos de pipeline que o estágio usa, incluindo ambientes. Os ambientes podem ter verificações que precisam ser satisfeitas.

Uma aprovação é um tipo de verificação. Ao configurar uma verificação de aprovação, você atribui um ou mais avaliadores que precisam aprovar o prosseguimento do pipeline.

O Azure Pipelines também fornece outros tipos de verificações. Por exemplo, você pode chamar uma API para executar a lógica personalizada, controlar o horário comercial durante o qual um estágio pode ser executado e até mesmo consultar o Azure Monitor para garantir que uma implantação tenha êxito. Somente verificações de aprovação são discutidas neste módulo, mas o resumo do módulo inclui links para mais informações sobre verificações.

Depois que o pipeline é iniciado e atinge uma fase que exige uma verificação de aprovação, a execução de pipeline é colocada em pausa. Todos os revisores que foram designados como aprovadores são enviados uma mensagem no Azure DevOps e por email.

Os aprovadores podem inspecionar os logs do pipeline, como as alterações detectadas pela operação de teste de hipóteses. Com nessas informações, eles aprovam ou recusam a alteração. Se eles aprovarem a alteração, o pipeline será retomado. Se eles a recusarem ou se não responderem dentro de um tempo limite configurável, a fase falhará.

A importância de boas práticas

O recurso de ambientes no Azure Pipelines oferece a capacidade de vincular suas implantações a um ambiente. A implantação herda as verificações e aprovações definidas pelo proprietário do ambiente. No entanto, não há nada que exige que os novos pipelines usem os ambientes.

É importante que você e sua organização estabeleçam boas práticas para examinar suas definições de pipeline. Um exemplo é configurar seu repositório para exigir revisões de solicitação de pull em todas as alterações na ramificação principal usando políticas de proteção de branch. Você aprenderá mais sobre esse conceito em um próximo módulo.

Você também pode adicionar verificações e aprovações às conexões de serviço para garantir que a aprovação seja obtida antes que uma implantação possa usar as credenciais da entidade de serviço. No entanto, as aprovações também afetariam a capacidade do pipeline de executar a validação prévia e a operação de teste de hipóteses, pois elas também exigem uma conexão de serviço.

Você pode usar outra conexão de serviço separada para a fase de teste de hipóteses com uma entidade de serviço própria. A entidade de serviço usada para as etapas de validação prévia e validação precisa ter uma função personalizada do Azure definida para garantir que ela tenha as permissões mínimas necessárias para fazer seu trabalho.