Teste seus recursos após a implantação

6 minutos

Ao validar e visualizar sua implantação do Bicep, você foi capaz de criar confiança de que seus arquivos do Bicep serão implantados com êxito. Mas a implantação não é a história toda. Após a conclusão da implantação, também é útil verificar se a implantação fez o esperado.

Nesta unidade, você aprenderá sobre os testes que podem ser executados após a conclusão da implantação. Você também aprenderá sobre como reverter sua implantação, se as coisas não saírem como você esperava.

Realizar testes de fumo e testes negativos

Quando você define recursos em um arquivo Bicep, sua meta não é apenas criar recursos no Azure. É agregar valor à sua organização, ao mesmo tempo em que atende aos requisitos da sua organização. Ao validar e visualizar seus arquivos Bicep, você ganha confiança de que as definições de recursos são válidas. Mas você não sabe necessariamente que os recursos realmente fazem o que você quer.

Por exemplo, imagine que você implante um novo servidor lógico SQL do Azure usando um fluxo de trabalho de implantação do Bicep. Sua definição de Bicep para o servidor é válida, portanto, passa nos trabalhos de validação de linter e comprovação. O comando what-if mostra que um servidor será criado, que é o que você espera. A implantação também é concluída com êxito. Mas, no final do processo de implantação, talvez você ainda não tenha um servidor de banco de dados em funcionamento pronto para uso. As razões podem incluir:

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

Mesmo quando você está apenas implantando arquivos básicos do Bicep, vale a pena considerar como você pode validar se os recursos implantados realmente funcionam e atendem às suas necessidades. Eis alguns exemplos de como pode aplicar este princípio:

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

Esses testes às vezes são chamados de testes de fumaça de infraestrutura. O teste de fumaça é uma forma simples de teste projetada para descobrir os principais problemas em sua implantação.

Nota

Alguns recursos do Azure não são fáceis de alcançar a partir de corredores hospedados no GitHub. Talvez seja necessário considerar o uso de um corredor auto-hospedado para executar trabalhos de teste de fumaça se eles precisarem de acesso a recursos por meio de redes privadas.

Também é uma boa ideia realizar testes negativos. O teste negativo ajuda-o a confirmar que os seus 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. Você pode adicionar um teste negativo ao seu fluxo de trabalho para verificar se não é possível se conectar diretamente a uma máquina virtual usando a Conexão de Área de Trabalho Remota ou SSH.

Importante

O objetivo desses testes não é verificar se o Bicep implantou seus recursos corretamente. Ao usar o Bicep, você está assumindo que ele implantará os recursos especificados em seus arquivos Bicep. Em vez disso, o objetivo é verificar se os recursos que você definiu funcionam para sua situação e atendem às suas necessidades.

Executar testes a partir de fluxos de trabalho do GitHub

Há muitas maneiras de executar testes em seu fluxo de trabalho. Neste módulo, usamos o Pester, que é uma ferramenta de código aberto que executa testes escritos por meio do PowerShell. O Pester está pré-instalado em corredores hospedados no GitHub. Você não precisa fazer nada de especial para usá-lo em uma etapa de script.

Você pode optar por usar uma estrutura de teste diferente ou até mesmo optar por executar seus testes sem uma ferramenta de teste. Por exemplo, outra ferramenta de teste a considerar é o PSRule para Azure, que inclui regras e testes pré-criados para o Azure. Ele pode executar a validação em seus modelos e também executar testes em relação aos recursos implantados do Azure. Nós ligamos para PSRule no resumo.

Quando você executa testes de um fluxo de trabalho, quaisquer falhas de teste devem impedir que o fluxo de trabalho continue. No próximo exercício, você verá como pode usar fluxos de trabalho com testes de fumaça 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 que podem exibir e acompanhar os resultados do teste ao longo do tempo.

Passar dados entre trabalhos

Quando você divide seu fluxo de trabalho em vários trabalhos, cada um com sua própria responsabilidade, às vezes você precisa passar dados entre esses trabalhos. Por exemplo, um trabalho pode criar um recurso do Azure com o qual outro trabalho precisa trabalhar. Para poder passar dados, o segundo trabalho precisa saber o nome do recurso que foi criado. Por exemplo, nosso trabalho de teste de fumaça precisa acessar os recursos que o trabalho de implantação implantou.

Seu arquivo Bicep implanta os recursos, para que ele possa acessar as propriedades do recurso e publicá-los como saídas de implantação. Quando você executa a implantação do Bicep por meio da arm-deploy ação, essa ação armazena essas saídas de implantação do Bicep em suas saídas de etapa. Em seguida, o trabalho que mantém a arm-deploy ação agora pode publicar essas saídas de etapa como saídas de trabalho. O trabalho faz referência à propriedade da id 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 isso dependa do trabalho que produz o resultado:

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 passar saídas de um script de fluxo de trabalho usando uma sintaxe especial. Temos links para mais informações no resumo.

Outros tipos de ensaio

Testes funcionais e testes de integração são frequentemente usados para validar se os recursos implantados se comportam como você espera. Por exemplo, um teste de integração pode se conectar ao seu site e enviar uma transação de teste e, em seguida, aguardar para confirmar que a transação foi concluída com êxito. Usando testes de integração, você pode testar a solução que sua equipe cria, juntamente com a infraestrutura em que ela está sendo executada. Em um módulo futuro, você verá como esses tipos de testes podem ser adicionados ao seu fluxo de trabalho.

Também é possível executar outros tipos de testes a partir 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 rolar para a frente

Suponha que seu fluxo de trabalho implante seus recursos com êxito, mas seus testes falhem. O que fazer então?

No início deste módulo, você aprendeu que as Ações do GitHub permitem 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 as alterações ou executar novamente todo o fluxo de trabalho, se achar que a falha se deveu a um problema temporário que já foi resolvido.

Nota

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

Por exemplo, você pode adicionar um trabalho de reversão ao seu fluxo de trabalho. O trabalho de reversão é executado quando o trabalho de teste de fumaça falha:

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

O trabalho depende do trabalho de teste de fumaça. Só funciona quando o teste de fumo falha. Por padrão, as Ações do GitHub interrompem o fluxo de trabalho sempre que um trabalho anterior falha. A if condição inclui uma always() verificação para substituir esse comportamento. Sem o always() na expressão, o trabalho de reversão é ignorado sempre que um trabalho anterior falha.

Muitas vezes, é um desafio descobrir as etapas que um trabalho de reversão deve executar. Em geral, as implantações do Bicep são complexas e não é fácil reverter as alterações. É especialmente difícil reverter quando sua implantação inclui outros componentes.

Por exemplo, imagine que seu fluxo de trabalho implanta um arquivo Bicep que define um banco de dados SQL do Azure e, em seguida, adiciona alguns dados ao banco de dados. Quando sua implantação é revertida, os dados devem ser excluídos? A base de dados também deve ser removida? É difícil prever como cada falha e cada reversão pode afetar seu ambiente de execução.

Por esse motivo, muitas organizações preferem avançar, o que significa que corrigem rapidamente o motivo da falha e, em seguida, implantam novamente. Ao criar um processo de implantação automatizado de alta qualidade e seguir todas as práticas recomendadas que você aprendeu ao longo desses caminhos de aprendizagem, você poderá corrigir problemas rapidamente e reimplantar seus arquivos Bicep, mantendo a alta qualidade.

Gorjeta