Teste seus recursos após a implantação

6 minutos

Ao validar e visualizar sua implantação do Bicep, você conseguiu 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 e, ao mesmo tempo, atender aos requisitos da mesma. Quando você valida e visualiza seus arquivos Bicep, ganha confiança de que as definições de recursos são válidas, mas não necessariamente sabe que os recursos realmente farão o que você deseja.

Por exemplo, imagine que você implante um novo servidor lógico SQL do Azure usando um pipeline de implantação do Bicep. Sua definição de Bicep para o servidor é válida, portanto, passa pelas etapas de validação linter e preflight. 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 chegue 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 pipeline. Verifique se o pipeline se conecta ao site com êxito e se 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 pipeline se conecta à CDN com êxito e 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 um agente de pipeline hospedado pela Microsoft. Talvez seja necessário considerar o uso de um agente auto-hospedado para executar estágios de teste de fumaça se eles exigirem 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 pipeline para verificar se não é possível se conectar a uma máquina virtual diretamente 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 funcionarão para sua situação e atenderão às suas necessidades.

Executar testes a partir do Azure Pipelines

Há muitas maneiras de executar testes em seu pipeline. Neste módulo, usaremos o Pester, que é uma ferramenta de código aberto que executa testes escritos por meio do PowerShell. 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. Vamos ligar para PSRule no resumo.

Quando você usa uma estrutura de teste com suporte, o Azure Pipelines entende os resultados de cada teste. Ele exibe os resultados do teste ao lado das informações de execução do pipeline e rastreia o histórico de cada teste ao longo do tempo. No próximo exercício, você verá como pode usar os Pipelines do Azure com testes de fumaça de infraestrutura.

Passar dados entre etapas e estágios

Quando você divide seu pipeline em vários estágios, cada um com sua própria responsabilidade, às vezes você precisa passar dados entre esses estágios. Por exemplo, um estágio pode criar um recurso do Azure com o qual outro estágio precisa trabalhar. Para poder passar dados, a segunda etapa precisa saber o nome do recurso que foi criado. Por exemplo, nosso estágio de teste de fumaça precisa acessar os recursos que o estágio 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. Você pode acessar uma saída de implantação em seu pipeline. No Azure Pipelines, há uma sintaxe especial para publicar variáveis para disponibilizá-las entre estágios.

Primeiro, você precisa publicar uma variável de saída para um estágio de pipeline. Para gerar a variável, você gravará uma cadeia de caracteres especialmente formatada no log de pipeline, que o Azure Pipelines sabe como entender. No exemplo a seguir, uma variável chamada myVariable é definida como o valor myValue:

echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"

O Azure Pipelines lê e interpreta a cadeia de caracteres do log de pipeline e disponibiliza o valor da variável como uma saída. Você pode combinar esse valor com mais scripts para publicar o valor de uma saída de implantação do Bicep como uma variável de saída para um estágio de pipeline. Você verá como fazer esse script no próximo exercício.

Em segundo lugar, você precisa disponibilizar a variável para o trabalho da sua etapa de teste de fumaça. Você definirá uma variável para o trabalho e usará outra cadeia de caracteres YAML especialmente formatada:

- stage: SmokeTest
  jobs:
  - job: SmokeTest
    variables:
      myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]

Agora, qualquer etapa dentro do trabalho de teste de fumaça pode acessar o myVariable valor como qualquer outra variável, usando a sintaxe $(myVariable). Você usará uma variável no próximo exercício.

Outros tipos de ensaio

Testes funcionais e testes de integração são frequentemente usados para validar se os recursos implantados estão se comportando 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 na qual ela está sendo executada. Em um módulo futuro, você verá como esses tipos de testes podem ser adicionados ao seu pipeline.

Também é possível executar outros tipos de testes a partir de um pipeline 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 pipeline implante seus recursos com êxito, mas seus testes falham. O que fazer então?

No início deste módulo, você aprendeu que o Azure Pipelines permite criar estágios de reversão que são executados quando um estágio anterior falha. Você pode usar essa abordagem para criar um estágio de reversão quando o estágio de teste relatar um resultado inesperado. Você também pode reverter manualmente suas alterações ou executar novamente todo o pipeline, se achar que a falha foi devido 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 novamente sua última implantação bem-sucedida se ela falhar. Para fazer isso, você precisa usar a etapa da CLI do Azure para implantar seu arquivo e adicionar o --rollback-on-error parâmetro ao enviar a implantação usando o az deployment group create comando.

Muitas vezes, é desafiador descobrir as etapas que um estágio 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 pipeline 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