Desenvolvimento Orientado por Testes para zonas de destino do Azure
O TDD (Desenvolvimento Orientado por Testes) é um processo de desenvolvimento de software e DevOps que melhora a qualidade de novos recursos e aprimoramentos nas soluções baseadas em código. O TDD cria casos de teste de unidade, antes de desenvolver o código real e testa o código em relação aos casos de teste. Essa abordagem é o contrário de desenvolver o código primeiro e criar os casos de teste depois.
Uma zona de destino é um ambiente para hospedar as cargas de trabalho pré-provisionadas por meio do código. As zonas de destino incluem recursos fundamentais que usam um conjunto definido de serviços de nuvem e melhores práticas. Este artigo descreve uma abordagem que usa o TDD para implantar zonas de destino bem-sucedidas, enquanto atende aos requisitos de qualidade, segurança, operações e governança.
A infraestrutura de nuvem é a saída da execução do código. Um código bem estruturado, testado e verificado produz uma zona de destino viável. A infraestrutura baseada em nuvem e o código-fonte subjacente podem usar essa abordagem para garantir que as zonas de destino sejam de alta qualidade e atendam aos principais requisitos.
Use essa abordagem para atender a solicitações de recursos simples, durante o desenvolvimento inicial. Posteriormente no ciclo de vida de adoção da nuvem, você poderá usar esse processo para atender aos requisitos de segurança, operações, governança ou conformidade. O processo é especialmente útil para desenvolver e refatorar zonas de destino em uma tentativa de desenvolvimento paralela.
Ciclo de desenvolvimento orientado por testes
O diagrama a seguir mostra o ciclo de Desenvolvimento Orientado por Testes para zonas de destino do Azure:
Crie um teste. Defina um teste para validar se os critérios de aceitação de um recurso foram atendidos. Automatize o teste conforme você desenvolve, para reduzir os esforços de teste manual, especialmente para implantações em escala empresarial.
Teste a zona de destino. Execute o novo teste e os testes existentes. Se o recurso necessário não foi incluído nas ofertas do provedor de nuvem e não foi fornecido por esforços de desenvolvimento anteriores, o teste deve falhar. A execução dos testes existentes ajuda a validar se o novo recurso ou teste não reduz a confiabilidade dos recursos existentes da zona de destino.
Expanda e refatore a zona de destino. Adicione ou modifique o código-fonte para atender ao recurso de valor agregado solicitado e melhorar a qualidade geral da base de código.
Para atender aos critérios de TDD, a equipe da plataforma de nuvem adiciona o código apenas para atender ao recurso solicitado. No entanto, a qualidade e a manutenção do código são esforços compartilhados. À medida que eles atendem às novas solicitações de recursos, a equipe de plataforma de nuvem deve buscar melhorar o código, removendo a duplicação e esclarecendo o código. É altamente recomendável executar testes entre a criação de novos códigos e a refatoração do código-fonte.
Implante a zona de destino. Depois que o código-fonte atende à solicitação de recursos, implante a zona de destino modificada no provedor de nuvem em um ambiente de área restrita ou teste controlado.
Teste a zona de destino. Reteste a zona de destino para validar se o novo código atende aos critérios de aceitação do recurso solicitado. Depois que todos os testes são aprovados, o recurso é considerado completo e os critérios de aceitação são considerados atendidos.
O ciclo de TDD repete as etapas básicas anteriores até que atendam à definição completa de concluído. Quando todos os recursos de valor agregado e os critérios de aceitação passam em seus testes associados, a zona de destino está pronta para dar suporte à próxima onda do plano de adoção de nuvem.
O ciclo que torna o TDD eficaz geralmente é conhecido como um teste vermelho/verde. Nessa abordagem, a equipe de plataforma de nuvem começa com um teste com falha ou teste vermelho, baseado na definição de concluído e nos critérios de aceitação definidos. Para cada recurso ou critério de aceitação, a equipe de plataforma de nuvem conclui as tarefas de desenvolvimento até que o teste seja aprovado ou apresente um teste verde.
O objetivo do TDD é analisar um design melhor, e não criar um pacote de testes. Os testes são um artefato importante para concluir o processo.
Definição de concluído
O sucesso pode ser uma medida subjetiva, que fornece a uma equipe de plataforma de nuvem poucas informações acionáveis durante o desenvolvimento ou a refatoração da zona de destino. A falta de clareza pode levar a expectativas não atendidas e a vulnerabilidades em um ambiente de nuvem. Antes que a equipe da plataforma de nuvem refatore ou expanda as zonas de destino, ela deve buscar clareza quanto à DoD (definição de concluído) para cada zona de destino.
O DoD é um contrato simples entre a equipe da plataforma de nuvem e outras equipes afetadas, o qual define os recursos de valor agregado esperados a serem incluídos nos esforços de desenvolvimento da zona de destino. A definição de DoD geralmente é uma lista de verificação alinhada ao plano de adoção de nuvem de curto prazo.
À medida que as equipes adotam mais cargas de trabalho e recursos de nuvem, o DoD e os critérios de aceitação se tornam mais complexos. Em processos maduros, os recursos esperados têm seus próprios critérios de aceitação para fornecer mais clareza. Quando todos os recursos de valor agregado atendem aos critérios de aceitação, a zona de destino está configurada o suficiente para permitir o sucesso do ciclo ou da liberação atual de adoção.
Exemplo de DoD simples
Para os esforços iniciais de migração, o DoD pode ser excessivamente simples. O exemplo a seguir é um DoD simples:
A zona de destino inicial hospedará dez cargas de trabalho para fins de aprendizado inicial. Essas cargas de trabalho não são críticas aos negócios e não têm acesso a dados confidenciais. No futuro, essas cargas de trabalho provavelmente serão liberadas para a produção, mas a criticidade e a confidencialidade não devem mudar.
Para dar suporte a essas cargas de trabalho, a equipe de adoção de nuvem precisa atender aos seguintes critérios:
- Segmentação de rede para alinhamento com o design de rede proposto. Esse ambiente deve ser uma rede de perímetro com acesso à Internet pública.
- Acesso a recursos de computação, armazenamento e rede para hospedar as cargas de trabalho alinhadas à descoberta de propriedade digital.
- Esquema de nomeação e marcação para facilitar o uso.
- Durante a adoção, acesso temporário para que a equipe de adoção da nuvem altere as configurações do serviço.
- Antes da versão de produção, integração com o provedor de identidade corporativa para reger a identidade e o acesso contínuos para gerenciamento de operações. Nesse momento, o acesso da equipe de adoção de nuvem deve ser revogado.
O último ponto não é um recurso ou critério de aceitação, mas um indicador de que mais expansões serão necessárias e devem ser exploradas com outras equipes antecipadamente.
Exemplos de DoD mais complexo
A metodologia de governança do Cloud Adoption Framework fornece um percurso narrativo pela maturidade natural de uma equipe de governança. Nesse percurso, há vários exemplos de DoD e critérios de aceitação na forma de instruções de política.
Declarações iniciais de política. Exemplo de DoD inicial com base em políticas corporativas que regem os requisitos de adoção no estágio inicial.
Melhorias incrementais para expandir o gerenciamento de identidades. Exemplo de políticas corporativas que regem o DoD para atender aos requisitos de expansão do gerenciamento de identidade de uma zona de destino.
Melhorias incrementais para expandir os requisitos de segurança. Exemplo de políticas corporativas que regem o DoD para atender aos requisitos de segurança alinhados ao plano de adoção de nuvem de referência.
Melhorias incrementais para expandir o gerenciamento de operações. Exemplo de políticas corporativas que regem o DoD para atender aos requisitos básicos de gerenciamento de operações.
Melhorias incrementais para expandir o gerenciamento de custos. Exemplo de políticas corporativas que regem o DoD para atender aos requisitos de gerenciamento de custos.
Os exemplos anteriores são amostras básicas para ajudar a desenvolver um DoD para as zonas de destino. Você pode obter políticas de exemplo para cada uma das Cinco Disciplinas de Governança de Nuvem.
Ferramentas e recursos do Azure para dar suporte ao TDD da zona de destino
O diagrama a seguir mostra as ferramentas de Desenvolvimento Orientado por Testes disponíveis no Azure:
Você pode integrar facilmente essas ferramentas e recursos do Azure ao TDD para criação da zona de destino. As ferramentas atendem a finalidades específicas, facilitando o desenvolvimento, o teste e a implantação das zonas de destino em alinhamento com os ciclos de TDD.
O Azure Resource Manager fornece uma plataforma consistente para processos de compilação e implantação. A plataforma do Resource Manager pode implantar zonas de destino com base nas definições de código-fonte.
Os Modelos do ARM fornecem o código-fonte primário para ambientes implantados no Azure. Algumas ferramentas de terceiros, como o Terraform, fornecem seus próprios modelos do ARM para enviar ao Azure Resource Manager.
Os Modelos de Início Rápido do Azure fornecem modelos de código-fonte que ajudam a acelerar a implantação de zonas de destino e de cargas de trabalho.
O Azure Policy fornece o mecanismo principal para testar os critérios de aceitação no DoD. O Azure Policy pode fornecer detecção, proteção e resolução automatizadas, quando as implantações se desviam das políticas de governança.
Em um ciclo de TDD, você pode criar uma definição de política para testar um único critério de aceitação. O Azure Policy inclui definições de política internas que podem atender a critérios de aceitação individuais em um DoD. Essa abordagem fornece um mecanismo para testes vermelhos, antes que você modifique a zona de destino.
O Azure Policy também inclui iniciativas de política internas, que você pode usar para testar e impor o DoD completo para uma zona de destino. Você podem adicionar todos os critérios de aceitação a uma iniciativa de política atribuída a toda a assinatura. Depois que a zona de destino atende ao DoD, o Azure Policy pode impor os critérios de teste para evitar alterações de código que possam fazer com que o teste falhe em versões futuras.
Crie e examine os fluxos de trabalho do Azure Policy como Código como parte da abordagem de TDD.
O Azure Blueprints agrupa as políticas e outras ferramentas de implantação em um pacote repetível, que você pode atribuir a várias zonas de destino. Os Blueprints são úteis para vários esforços de adoção que compartilham DoDs comuns, que você deve atualizar ao longo do tempo. Os Azure Blueprints também podem ajudar com a implantação durante os esforços subsequentes para expandir e refatorar zonas de destino.
O Azure Blueprints fornece vários exemplos de blueprint, incluindo políticas para teste e modelos para implantação. Esses exemplos de blueprint podem acelerar os esforços de desenvolvimento, implantação e teste em ciclos de TDD.
O Azure Resource Graph fornece uma linguagem de consulta para criar testes orientados por dados com base nas informações sobre os ativos implantados em uma zona de destino. Posteriormente no plano de adoção, essa ferramenta também pode definir testes complexos com base nas interações entre os ativos de carga de trabalho e o ambiente de nuvem subjacente.
O Resource Graph inclui exemplos de consulta avançados, que você pode usar para entender como as cargas de trabalho são implantadas em uma zona de destino para cenários de teste avançados.
Dependendo da abordagem preferencial, você também pode usar as seguintes ferramentas:
- Implante as zonas de destino usando o Terraform.
- Implante as zonas de destino usando o Bicep.
- Gerencie as zonas de destino usando o AzOps, um módulo do PowerShell que envia os modelos de recursos e arquivos Bicep em todos os níveis de escopo do Azure e extrai e exporta as hierarquias de recursos do Azure.