Testar seus recursos após a implantação

6 minutos

Ao validar e pré-visualizar a implantação do Bicep, você conseguiu criar confiança de que os arquivos Bicep serão implantados com êxito. Mas a implantação não é a história completa. Após a conclusão da implantação, também é útil verificar se ela fez o que você esperava.

Nesta unidade, você aprenderá mais sobre os testes que podem ser executados após a conclusão da implantação. Você também verá como reverter a implantação se as coisas não funcionarem conforme o esperado.

Executar smoke tests e testes negativos

Quando você define recursos em um arquivo Bicep, sua meta não é apenas criar recursos no Azure. A meta é agregar valor à sua organização, atendendo também aos requisitos dela. Ao validar e visualizar os arquivos Bicep, você aumentará sua confiança na validade das definições de recurso. Mas você não sabe necessariamente se os recursos realmente fazem o que você deseja.

Por exemplo, imagine que você implantou um novo servidor lógico SQL do Azure usando um fluxo de trabalho de implantação do Bicep. Sua definição do Bicep para o servidor é válida, portanto, ela é aprovada nos trabalhos de linter e de validação de comprovação. O comando de teste de hipóteses mostra que um servidor será criado, o que é o esperado. A implantação também é concluída com sucesso. No entanto, no final do processo de implantação, é possível que você ainda não tenha um servidor de banco de dados funcionando e pronto para uso. Os motivos podem incluir:

Você não configurou regras de firewall para permitir que o tráfego de rede chegue ao seu servidor.
Você habilitou a autenticação do Microsoft Entra em seu servidor quando não deveria, ou vice-versa.

Mesmo quando você só está implantando arquivos Bicep básicos, vale a pena considerar como validar se os recursos implantados realmente funcionam e atendem às suas necessidades. Veja alguns exemplos de aplicação deste princípio:

Ao implantar um site, tente acessar o aplicativo Web pelo fluxo de trabalho. Verifique se o fluxo de trabalho se conecta ao site com êxito e recebe um código de resposta válido.
Ao implantar uma CDN (rede de distribuição de conteúdo), tente se conectar a um recurso por meio dela. Verifique se o fluxo de trabalho se conecta à CDN com êxito e recebe um código de resposta válido.

Às vezes, esses testes são chamados de smoke tests de infraestrutura. O smoke test é uma forma simples de teste projetada para descobrir os principais problemas na implantação.

Observação

Alguns recursos do Azure não são fáceis de acessar com os executores hospedados no GitHub. Você pode precisar considerar o uso de um executor auto-hospedado para executar trabalhos de smoke test caso eles requeiram acesso a recursos por meio de redes privadas.

Também é uma boa ideia executar um teste negativo. O teste negativo ajuda você a confirmar se os recursos não têm um comportamento indesejado. Por exemplo, quando você implanta uma máquina virtual, é uma boa prática usar o Azure Bastion para se conectar com segurança à máquina virtual. É possível adicionar um teste negativo ao fluxo de trabalho para verificar a impossibilidade de conexão direta com uma máquina virtual usando a Conexão de Área de Trabalho Remota ou SSH.

Importante

A meta desses testes não é verificar se o Bicep implantou seus recursos corretamente. Usando o Bicep, você está supondo que ele implantará os recursos especificados nos arquivos Bicep. Em vez disso, o objetivo é verificar se os recursos que você definiu funcionam para a sua situação e atendem aos seus requisitos.

Executar testes de fluxos de trabalho do GitHub

Há muitas maneiras de executar testes no fluxo de trabalho. Este módulo usa o Pester, que é uma ferramenta de código aberto que executa testes escritos pelo PowerShell. O Pester é pré-instalado em executores hospedados no GitHub. Você não precisa fazer nada especial para usá-los em uma etapa de script.

Você pode optar por usar uma estrutura de teste diferente ou até mesmo executar testes sem uma ferramenta de teste. Por exemplo, outra ferramenta de teste a ser considerada é o PSRule para Azure, que inclui testes e regras predefinidos para o Azure. Ele pode executar a validação nos modelos e executar testes os recursos do Azure implantados. Fornecemos o link para o PSRule no resumo.

Quando você executa testes por um fluxo de trabalho, qualquer falha no teste interrompe a continuação do fluxo de trabalho. No próximo exercício, você verá como usar fluxos de trabalho com smoke tests de infraestrutura.

Os resultados do teste são gravados no log do fluxo de trabalho. O GitHub Marketplace também contém ações que não são da Microsoft e que podem exibir e rastrear os resultados dos testes ao longo do tempo.

Transmitir dados entre trabalhos

Às vezes, ao dividir o fluxo de trabalho em vários trabalhos que contêm cada um a própria responsabilidade, você precisa transmitir dados entre esses trabalhos. Por exemplo, um trabalho pode criar um recurso do Azure com o qual outro trabalho precisa trabalhar. Para transmitir dados, o segundo trabalho precisa saber o nome do recurso criado. Por exemplo, nosso trabalho de smoke test precisa acessar os recursos que o trabalho de implantação implantou.

O arquivo Bicep implanta os recursos, de modo que ele possa acessar as propriedades do recurso e publicá-las como saídas da implantação. Quando você executa a implantação do Bicep por meio da ação arm-deploy, essa ação armazena essas saídas de implantação do Bicep em suas saídas de etapa. Em seguida, o trabalho que retém a ação arm-deploy agora pode publicar essas saídas de etapa como saídas de trabalho. O trabalho faz referência à propriedade id da etapa, que definimos como deploy:

deploy:
  runs-on: ubuntu-latest
  environment: Website
  needs: preview
  outputs:
    appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
  steps:
  - uses: actions/checkout@v3
  - 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
    id: deploy
    name: Deploy website
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Você pode acessar a saída de um trabalho em qualquer trabalho subsequente, desde que dependa do trabalho que produziu a saída:

smoke-test:
  runs-on: ubuntu-latest
  needs: deploy
  steps:
  - uses: actions/checkout@v3
  - run: |
      $container = New-PesterContainer `
        -Path 'deploy/Website.Tests.ps1' `
        -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
      Invoke-Pester `
        -Container $container `
        -CI
    name: Run smoke tests
    shell: pwsh

Você também pode transmitir saídas de um script de fluxo de trabalho usando uma sintaxe especial. Há um link para mais informações no resumo.

Outros tipos de testes

Os testes funcionais e os testes de integração são frequentemente usados para validar se os recursos implantados se comportam conforme o esperado. Por exemplo, um teste de integração pode se conectar ao site, enviar uma transação de teste e, depois, aguardar a confirmação de que ela foi concluída com êxito. Usando testes de integração, você pode testar a solução que sua equipe criou, além da infraestrutura que a executa. Em um módulo futuro, você verá como esses tipos de testes podem ser adicionados ao fluxo de trabalho.

Também é possível executar outros tipos de testes de um fluxo de trabalho de implantação, incluindo testes de desempenho e testes de penetração de segurança. Esses testes estão fora do escopo deste módulo, mas podem agregar valor a um processo de implantação automatizado.

Reverter ou efetuar roll forward

Suponha que seu fluxo de trabalho implante os recursos com sucesso, mas os testes falhem. O que fazer agora?

Anteriormente neste módulo, você aprendeu que o GitHub Actions permite criar trabalhos de reversão que são executados quando um trabalho anterior falha. Você pode usar essa abordagem para criar um trabalho de reversão quando o trabalho de teste relatar um resultado inesperado. Você também pode reverter manualmente suas alterações ou executar novamente todo o fluxo de trabalho, se achar que a falha foi causada por um problema temporário que já foi resolvido.

Observação

Ao enviar uma implantação para o Azure Resource Manager, você pode solicitar que o Resource Manager reexecute automaticamente sua última implantação bem-sucedida se ela falhar. Para isso, use o parâmetro --rollback-on-error ao enviar a implantação com o comando az deployment group create da CLI do Azure.

Por exemplo, você pode adicionar um trabalho de reversão ao fluxo de trabalho. O trabalho de reversão é executado quando o trabalho de smoke test falha:

rollback: 
  runs-on: ubuntu-latest
  needs: smoke-test
  if: ${{ always() && needs.smoke-test.result == 'failure' }}
  steps:
  - run: |
      echo "Performing rollback steps..."

Esse trabalho depende do trabalho de smoke test. Ele só é executado quando o smoke test falha. Por padrão, GitHub Actions interrompe o fluxo de trabalho sempre que um trabalho anterior falhar. A condição if inclui uma verificação always() para substituir esse comportamento. Sem o always() na expressão, o trabalho de reversão é ignorado sempre que um trabalho anterior falhar.

Costuma ser difícil compreender as etapas que um trabalho de reversão precisa executar. Em geral, as implantações do Bicep são complexas e não é fácil reverter alterações. É especialmente difícil revertê-las quando a implantação inclui outros componentes.

Por exemplo, imagine que o fluxo de trabalho implanta um arquivo Bicep que define um banco de dados SQL do Azure e adiciona alguns dados a ele. Quando a implantação é revertida, os dados devem ser excluídos? O banco de dados também deve ser removido? É difícil prever como cada falha e cada reversão podem afetar o ambiente em execução.

Por esse motivo, muitas organizações preferem efetuar roll forward, o que significa que elas corrigem rapidamente o motivo da falha e fazem a implantação de novo. Ao criar um processo de implantação automatizado de alta qualidade e seguir todas as melhores práticas que você aprendeu ao longo desses roteiros de aprendizagem, você poderá corrigir rapidamente os problemas e reimplantar os arquivos Bicep, mantendo a alta qualidade.

Dica