Desenvolvimento orientado a teste para zonas de aterrissagem do Azure
O desenvolvimento orientado a testes (TDD) é um processo de desenvolvimento de software e DevOps que melhora a qualidade de novos recursos e melhorias em 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 se opõe ao desenvolvimento de código primeiro e à criação de casos de teste posteriormente.
Uma zona de aterrissagem é um ambiente para hospedar cargas de trabalho que é pré-provisionado por meio de código. As zonas de aterrissagem incluem recursos fundamentais que usam um conjunto definido de serviços de nuvem e práticas recomendadas. Este artigo descreve uma abordagem que usa TDD para implantar zonas de pouso bem-sucedidas e, ao mesmo tempo, atender aos requisitos de qualidade, segurança, operações e governança.
A infraestrutura em nuvem é a saída da execução de código. Um código bem estruturado, testado e verificado produz uma zona de aterragem viável. A infraestrutura baseada em nuvem e seu código-fonte subjacente podem usar essa abordagem para garantir que as zonas de aterrissagem sejam de alta qualidade e atendam aos requisitos principais.
Use essa abordagem para atender a solicitações de recursos simples durante o desenvolvimento inicial. Mais tarde no ciclo de vida de adoção da nuvem, você pode usar esse processo para atender aos requisitos de segurança, operações, governança ou conformidade. O processo é especialmente útil para desenvolver e refatoração de zonas de desembarque em um esforço de desenvolvimento paralelo.
Ciclo de desenvolvimento orientado a testes
O diagrama a seguir mostra o ciclo de desenvolvimento controlado por teste para zonas de aterrissagem 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 à medida que você desenvolve, para reduzir a quantidade de esforço de teste manual, especialmente para implantações em escala empresarial.
Teste a zona de aterragem. Execute o novo teste e quaisquer testes existentes. Se o recurso necessário não estiver incluído nas ofertas do provedor de nuvem e não tiver sido fornecido por esforços de desenvolvimento anteriores, o teste deverá falhar. A execução de testes existentes ajuda a validar que seu novo recurso ou teste não reduz a confiabilidade dos recursos existentes da zona de aterrissagem.
Expanda e refatore a zona de pouso. 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 TDD, a equipe da plataforma de nuvem adicionaria 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 atendem às novas solicitações de recursos, a equipe da plataforma de nuvem deve tentar melhorar o código removendo a duplicação e esclarecendo o código. A execução de testes entre a criação de novo código e a refatoração do código-fonte é altamente recomendada.
Implante a zona de pouso. Assim que o código-fonte atender à solicitação de recurso, implante a zona de aterrissagem modificada no provedor de nuvem em um ambiente de teste controlado ou sandbox.
Teste a zona de aterragem. Teste novamente a zona de aterrissagem para validar se o novo código atende aos critérios de aceitação do recurso solicitado. Uma vez que todos os testes sejam aprovados, o recurso é considerado completo e os critérios de aceitação são considerados atendidos.
O ciclo TDD repete as etapas básicas anteriores até que elas atendam à definição completa de concluído. Quando todos os recursos de valor agregado e critérios de aceitação passarem nos testes associados, a zona de pouso estará pronta para suportar a próxima onda do plano de adoção da nuvem.
O ciclo que torna o TDD eficaz é muitas vezes referido como um teste vermelho/verde. Nessa abordagem, a equipe da plataforma de nuvem começa com um teste reprovado, ou teste vermelho, com base 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 da plataforma de nuvem conclui as tarefas de desenvolvimento até que o teste seja aprovado ou tenha um teste verde.
O objetivo do TDD é abordar um melhor design, não criar um conjunto de testes. Os testes são um artefato valioso para completar 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 refatoração da zona de aterrissagem. A falta de clareza pode levar a expectativas perdidas e vulnerabilidades em um ambiente de nuvem. Antes que a equipe da plataforma de nuvem refatore ou expanda quaisquer zonas de pouso, eles devem buscar clareza sobre a definição de done (DoD) para cada zona de pouso.
O DoD é um acordo simples entre a equipe da plataforma de nuvem e outras equipes afetadas que define os recursos de valor agregado esperados a serem incluídos no esforço de desenvolvimento da zona de aterrissagem. O DoD geralmente é uma lista de verificação alinhada com o 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, cada um dos recursos esperados tem 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 pouso é suficientemente configurada para permitir o sucesso da atual onda de adoção ou lançamento.
Exemplo simples do DoD
Para um esforço inicial de migração, o DoD pode ser excessivamente simples. O exemplo a seguir é um DoD simples:
A zona de desembarque inicial abrigará 10 cargas de trabalho para fins de aprendizagem inicial. Essas cargas de trabalho não são críticas para os negócios e não têm acesso a dados confidenciais. No futuro, essas cargas de trabalho provavelmente serão liberadas para produção, mas não se espera que a criticidade e a sensibilidade mudem.
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 alinhar com o projeto de rede proposto. Este 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 facilidade de uso.
- Durante a adoção, acesso temporário para a equipe de adoção de nuvem alterar as configurações de serviço.
- Antes do lançamento da produção, integração com o provedor de identidade corporativa para controlar a identidade contínua e o acesso 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 mais cedo.
Exemplos mais complexos do DoD
A metodologia Govern dentro do Cloud Adoption Framework fornece uma jornada narrativa através da maturidade natural de uma equipe de governança. Embutidos nessa jornada estão vários exemplos de DoD e critérios de aceitação, na forma de declarações de políticas.
Declarações de política iniciais. Exemplo de DoD inicial baseado em políticas corporativas que regem os requisitos de adoção em 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 para 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 da 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 a gestão de custos. Exemplo de políticas corporativas que regem o DoD para atender aos requisitos de gerenciamento de custos.
Os exemplos anteriores são exemplos básicos para ajudá-lo a desenvolver um DoD para suas zonas de pouso. Você pode obter exemplos de políticas para cada uma das Cinco Disciplinas de Governança de Nuvem.
Ferramentas e recursos do Azure para dar suporte ao TDD da zona de aterrissagem
O diagrama a seguir mostra as ferramentas de desenvolvimento orientadas a teste disponíveis no Azure:
Você pode integrar facilmente essas ferramentas e recursos do Azure no TDD para a criação da zona de aterrissagem. As ferramentas servem propósitos específicos, facilitando o desenvolvimento, teste e implantação de zonas de pouso alinhadas com os ciclos TDD.
O Azure Resource Manager fornece uma plataforma consistente para processos de compilação e implantação. A plataforma Resource Manager pode implantar zonas de destino com base em definições de código-fonte.
Os modelos do Azure Resource Manager (ARM) fornecem código-fonte primário para ambientes implantados no Azure. Algumas ferramentas de terceiros, como o Terraform, fornecem seus próprios modelos 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 zona de aterrissagem e a implantação da carga de trabalho.
O Azure Policy fornece o mecanismo principal para testar os critérios de aceitação em seu DoD. A Política do Azure também pode fornecer deteção, proteção e resolução automatizadas quando as implantações se desviam das políticas de governança.
Em um ciclo TDD, você pode criar uma definição de política para testar um único critério de aceitação. A Política do Azure inclui definições de política internas que podem atender aos critérios de aceitação individuais em um DoD. Essa abordagem fornece um mecanismo para testes vermelhos antes de modificar a zona de pouso.
A Política do Azure também inclui iniciativas de política internas que você pode usar para testar e impor o DoD completo para uma zona de aterrissagem. Você pode adicionar todos os critérios de aceitação a uma iniciativa de política atribuída a toda a assinatura. Quando a zona de aterrissagem atende ao DoD, a Política do Azure pode impor os critérios de teste para evitar alterações de código que fariam com que o teste falhasse em versões futuras.
Projete e revise fluxos de trabalho da Política do Azure como Código como parte de sua abordagem TDD.
O Azure Resource Graph fornece uma linguagem de consulta para criar testes controlados por dados com base em informações sobre os ativos implantados em uma zona de aterrissagem. Mais adiante no plano de adoção, essa ferramenta também pode definir testes complexos com base nas interações entre ativos de carga de trabalho e o ambiente de nuvem subjacente.
O Resource Graph inclui exemplos de consulta avançada , que você pode usar para entender como as cargas de trabalho são implantadas em uma zona de aterrissagem para cenários de teste avançados.
Dependendo da sua abordagem preferida, você também pode usar as seguintes ferramentas:
- Implante zonas de pouso usando Terraform.
- Implante zonas de pouso usando o Bicep.
- Gerencie zonas de aterrissagem usando o AzOps, um módulo do PowerShell que envia por push modelos de recursos e arquivos Bicep em todos os níveis de escopo do Azure e extrai e exporta hierarquias de recursos do Azure.
Próximos passos
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários