Visualizar e aprovar sua implantação

  • 5 minutos

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

Nesta unidade, você aprenderá sobre como usar o comando what-if em um pipeline. Você também aprenderá sobre como adicionar aprovações 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 no 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.

Quando 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 quais recursos serão criados, atualizados e excluídos. 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 acontecerão no seu ambiente.

O Resource Manager fornece a operação hipotética, que você pode executar em seu arquivo Bicep dentro do estágio de pipeline:

Diagram of a pipeline that includes Lint, Validate, and Preview stages. The Preview stage executes a what-if operation against Azure.

Você pode usar o az deployment group what-if comando da CLI do Azure de dentro de sua definição de pipeline para executar a etapa hipotética:

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

Gorjeta

Neste módulo, usaremos a CLI do Azure para executar a operação hipotética. Se você criar seu próprio pipeline baseado em PowerShell, poderá usar o cmdlet com o New-AzResourceGroupDeployment-Whatif switch ou o Get-AzResourceGroupDeploymentWhatIfResult cmdlet.

A operação hipotética não faz alterações no seu ambiente. Em vez disso, ele descreve os recursos que serão criados ou excluídos, 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á. Esse feedback é chamado de ruído. Estamos a trabalhar para reduzir estes problemas, mas precisamos da sua ajuda para os denunciar.

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 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 pipeline.

Para saber mais sobre o comando what-if, consulte o módulo Microsoft Learn Preview Azure deployment changes by using what-if.

Ambientes

No Azure Pipelines, 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 futuro, você aprenderá mais sobre ambientes e seus recursos. Por enquanto, vamos nos concentrar na capacidade deles de adicionar aprovações manuais ao seu pipeline.

Como você já sabe, você usa trabalhos para definir uma sequência de etapas dentro de um estágio de pipeline. Ao incluir ambientes em seu pipeline, você precisa usar um tipo especial de trabalho chamado 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 de 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 deployment.
  • A environment palavra-chave especifica o nome do ambiente de destino. No exemplo anterior, a implantação é rastreada em relação a um ambiente chamado MyAzureEnvironment.
  • A strategy palavra-chave especifica como o Azure Pipelines executa as etapas de implantação. As estratégias de implantação oferecem suporte a processos de implantação complexos, especialmente quando você tem vários ambientes de produção. Neste módulo, usamos a estratégia de runOnce implantação. Essa estratégia se comporta de forma semelhante aos outros trabalhos aos quais você já está acostumado.

Verificações e aprovações por etapas

Depois de criar um ambiente, você pode definir verificações. As verificações são usadas para verificar as condições que devem ser atendidas antes que um pipeline possa usar o ambiente. Uma aprovação é um tipo de verificação que requer que um ser 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 ou adicionar essas verificações e aprovações. Somente os administradores de um ambiente podem gerenciar as verificações e aprovações nele.

Em muitas organizações, o proprietário de um ambiente no Azure Pipelines é a pessoa responsável pelo ambiente no qual ele implanta. As 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 aprovações?

As verificações e aprovações são avaliadas pouco antes do início de um estágio de pipeline. Quando o Azure Pipelines está prestes a executar um estágio de pipeline, ele examina 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 usuários que precisam aprovar a continuação do pipeline.

O Azure Pipelines também fornece outros tipos de verificação. Por exemplo, você pode chamar uma API para executar alguma 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 foi bem-sucedida. Discutimos apenas as verificações de aprovação neste módulo, mas fornecemos links para mais informações sobre verificações no resumo.

Nota

Os pools de agentes e as conexões de serviço também podem ter verificações configuradas neles. Você também pode usar uma etapa especial chamada tarefa de aprovação manual. No entanto, neste módulo, vamos nos concentrar nos ambientes e nas verificações associadas a eles.

Depois que o pipeline começa e atinge um estágio que requer uma verificação de aprovação, a execução do pipeline é pausada. Todos os usuários que foram designados como aprovadores recebem uma mensagem no Azure DevOps e por email.

Os aprovadores podem inspecionar os logs do pipeline, como as alterações que a operação hipotética deteta. Com base nessas informações, eles aprovam ou recusam a alteração. Se aprovarem a mudança, o pipeline será retomado. Se eles recusarem, ou se não responderem dentro de um período de tempo limite configurável, o estágio falhará.

Diagram of a pipeline that includes Lint, Validate, Preview, and Deploy stages, with an approval check before the Deploy stage.

A importância das boas práticas

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

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

Você também pode adicionar verificações e aprovações a conexões de serviço que garantem que a aprovação seja obtida antes que uma implantação possa usar as credenciais de uma entidade de serviço. No entanto, as aprovações também afetariam a capacidade do seu pipeline de executar a validação de comprovação e a operação hipotética, porque eles também exigem uma conexão de serviço.

Você pode usar outra conexão de serviço separada para o estágio hipotético com sua própria entidade de serviço. A entidade de serviço usada para os estágios de comprovação 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.