Desenvolvimento orientado para testes para zonas de destino do Azure
O desenvolvimento orientado para testes (TDD) é um processo de desenvolvimento de software e de DevOps que melhora a qualidade das novas funcionalidades e melhorias nas soluções baseadas em código. O TDD cria casos de teste de unidades antes de desenvolver o código real e testa o código nos casos de teste. Esta abordagem opõe-se primeiro ao desenvolvimento de código e à criação de casos de teste mais tarde.
Uma zona de destino é um ambiente para alojar cargas de trabalho pré-fornecidas através de código. As zonas de destino incluem capacidades fundamentais que utilizam um conjunto definido de serviços cloud e melhores práticas. Este artigo descreve uma abordagem que utiliza o TDD para implementar zonas de destino bem-sucedidas ao cumprir os requisitos de qualidade, segurança, operações e governação.
A infraestrutura de cloud é a saída da execução de código. Código bem estruturado, testado e verificado produz uma zona de destino viável. A infraestrutura baseada na cloud e o respetivo código fonte subjacente podem utilizar esta abordagem para garantir que as zonas de destino são de alta qualidade e cumprem os requisitos principais.
Utilize esta abordagem para satisfazer pedidos de funcionalidades simples durante o desenvolvimento antecipado. Mais à frente no ciclo de vida de adoção da cloud, pode utilizar este processo para cumprir os requisitos de segurança, operações, governação ou conformidade. O processo é especialmente útil para desenvolver e refatorizar zonas de destino num esforço de desenvolvimento paralelo.
Ciclo de desenvolvimento orientado para testes
O diagrama seguinte mostra o ciclo de desenvolvimento orientado para testes para as zonas de destino do Azure:
Criar um teste. Defina um teste para validar que os critérios de aceitação de uma funcionalidade foram cumpridos. Automatize o teste à medida que desenvolve, para reduzir a quantidade de esforços manuais de teste, especialmente para implementações à escala empresarial.
Teste a zona de destino. Execute o novo teste e quaisquer testes existentes. Se a funcionalidade necessária não estiver incluída nas ofertas do fornecedor de cloud e não tiver sido fornecida pelos esforços de desenvolvimento anteriores, o teste deverá falhar. A execução de testes existentes ajuda a validar que a nova funcionalidade ou teste não reduz a fiabilidade das funcionalidades de zona de destino existentes.
Expanda e refatorize a zona de destino. Adicione ou modifique o código fonte para cumprir a funcionalidade de valor acrescentado pedida e melhorar a qualidade geral da base de código.
Para cumprir os critérios do TDD, a equipa da plataforma cloud adicionaria código apenas para cumprir a funcionalidade pedida. No entanto, a qualidade e a manutenção do código são esforços partilhados. À medida que cumprem novos pedidos de funcionalidades, a equipa da plataforma cloud deve tentar melhorar o código ao remover a duplicação e clarificar o código. É altamente recomendado executar testes entre a criação de novo código e a refatorização do código fonte.
Implementar a zona de destino. Assim que o código fonte cumprir o pedido de funcionalidade, implemente a zona de destino modificada no fornecedor de cloud num ambiente de teste ou sandbox controlado.
Teste a zona de destino. Teste novamente a zona de destino para confirmar que o novo código cumpre os critérios de aceitação da funcionalidade pedida. Assim que todos os testes passarem, a funcionalidade é considerada concluída e os critérios de aceitação são considerados cumpridos.
O ciclo TDD repete os passos básicos anteriores até cumprirem a definição completa de concluído. Quando todas as funcionalidades de valor acrescentado e os critérios de aceitação passam nos testes associados, a zona de destino está pronta para suportar a próxima vaga do plano de adoção da cloud.
O ciclo que torna o TDD eficaz é frequentemente referido como um teste vermelho/verde. Nesta abordagem, a equipa da plataforma cloud começa com um teste falhado ou teste vermelho, com base na definição de concluído e nos critérios de aceitação definidos. Para cada funcionalidade ou critérios de aceitação, a equipa da plataforma cloud conclui as tarefas de desenvolvimento até o teste passar ou tem um teste verde.
O objetivo do TDD é abordar uma melhor estrutura e não criar um conjunto de testes. Os testes são um artefacto valioso para concluir o processo.
Definição de concluído
O êxito pode ser uma medida subjetiva que fornece poucas informações acionáveis a uma equipa da plataforma cloud durante o desenvolvimento ou refatorização da zona de destino. A falta de clareza pode levar a expectativas e vulnerabilidades perdidas num ambiente de cloud. Antes de a equipa da plataforma cloud refatorizar ou expandir quaisquer zonas de destino, devem procurar clareza relativamente à definição de concluído (DoD) para cada zona de destino.
O DoD é um contrato simples entre a equipa da plataforma cloud e outras equipas afetadas que definem as funcionalidades de valor acrescentado esperadas a incluir no esforço de desenvolvimento da zona de destino. O DoD é frequentemente uma lista de verificação alinhada com o plano de adoção da cloud de curto prazo.
À medida que as equipas adotam mais cargas de trabalho e funcionalidades da cloud, o DoD e os critérios de aceitação tornam-se mais complexos. Em processos maduros, as funcionalidades esperadas têm os seus próprios critérios de aceitação para proporcionar mais clareza. Quando as funcionalidades de valor acrescentado cumprem todos os critérios de aceitação, a zona de destino está suficientemente configurada para permitir o sucesso da onda ou versão de adoção atual.
Exemplo de DoD Simples
Para um esforço de migração inicial, o DoD pode ser excessivamente simples. O exemplo seguinte é um DoD simples:
A zona de destino inicial aloja 10 cargas de trabalho para fins de aprendizagem iniciais. Estas cargas de trabalho não são essenciais para a empresa e não têm acesso a dados confidenciais. No futuro, estas cargas de trabalho provavelmente serão lançadas para produção, mas não se espera que a crítica e a sensibilidade mudem.
Para suportar estas cargas de trabalho, a equipa de adoção da cloud tem de cumprir os seguintes critérios:
- Segmentação de rede para alinhar com a estrutura de rede proposta. Este ambiente deve ser uma rede de perímetro com acesso à Internet pública.
- Acesso a recursos de computação, armazenamento e rede para alojar as cargas de trabalho alinhadas com a deteção de propriedade digital.
- Atribuir nomes e etiquetar o esquema para facilitar a utilização.
- Durante a adoção, o acesso temporário à equipa de adoção da cloud para alterar as configurações do serviço.
- Antes da versão de produção, integração com o fornecedor de identidade empresarial para governar a identidade e o acesso contínuos para a gestão de operações. Nessa altura, o acesso da equipa de adoção da cloud deve ser revogado.
O último ponto não é uma funcionalidade ou critério de aceitação, mas um indicador de que serão necessárias mais expansões e que devem ser exploradas com outras equipas mais cedo.
Exemplos de DoD mais complexos
A metodologia governativa dentro do Cloud Adoption Framework proporciona um percurso narrativo através da maturidade natural de uma equipa de governação. Incorporados nesse percurso são vários exemplos de DoD e critérios de aceitação, na forma de declarações de política.
Instruções de política iniciais. Exemplo do DoD inicial baseado em políticas empresariais que regem os requisitos de adoção em fase inicial.
Melhorias incrementais para expandir a gestão de identidades. Exemplo de políticas empresariais que regem o DoD para cumprir os requisitos para expandir a gestão de identidades para uma zona de destino.
Melhorias incrementais para expandir os requisitos de segurança. Exemplo de políticas empresariais que regem o DoD para cumprir os requisitos de segurança alinhados com o plano de adoção da cloud de referência.
Melhorias incrementais para expandir a gestão de operações. Exemplo de políticas empresariais que regem o DoD para cumprir os requisitos básicos de gestão de operações.
Melhorias incrementais para expandir a gestão de custos. Exemplo de políticas empresariais que regem o DoD para cumprir os requisitos de gestão de custos.
Os exemplos anteriores são exemplos básicos para o ajudar a desenvolver um DoD para as suas zonas de destino. Pode obter políticas de exemplo para cada uma das Cinco Disciplinas de Governação da Cloud.
Ferramentas e funcionalidades do Azure para suportar o TDD da zona de destino
O diagrama seguinte mostra as ferramentas de desenvolvimento baseadas em testes disponíveis no Azure:
Pode integrar facilmente estas ferramentas e funcionalidades do Azure no TDD para a criação da zona de destino. As ferramentas servem fins específicos, facilitando o desenvolvimento, teste e implementação de zonas de destino em conformidade com os ciclos de TDD.
O Azure Resource Manager fornece uma plataforma consistente para processos de compilação e implementação. A plataforma Resource Manager pode implementar zonas de destino com base nas definições de código fonte.
Os modelos do Azure Resource Manager (ARM) fornecem código fonte principal para ambientes implementados no Azure. Algumas ferramentas de terceiros, como o Terraform, fornecem os seus próprios modelos arm para submeter ao Azure Resource Manager.
Os Modelos de Início Rápido do Azure fornecem modelos de código fonte que ajudam a acelerar a implementação da zona de destino e da carga de trabalho.
Azure Policy fornece o mecanismo principal para testar critérios de aceitação no Seu DoD. Azure Policy também podem fornecer deteção, proteção e resolução automatizadas quando as implementações se desviam das políticas de governação.
Num ciclo TDD, pode criar uma definição de política para testar um único critério de aceitação. Azure Policy inclui definições de política incorporadas que podem cumprir critérios de aceitação individuais num DoD. Esta abordagem fornece um mecanismo para testes vermelhos antes de modificar a zona de destino.
Azure Policy também inclui iniciativas de política incorporadas que pode utilizar para testar e impor o DoD completo para uma zona de destino. Pode adicionar todos os critérios de aceitação a uma iniciativa de política atribuída a toda a subscrição. Assim que a zona de destino cumprir o DoD, Azure Policy 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.
Crie e reveja Azure Policy como fluxos de trabalho de Código como parte da abordagem do TDD.
O Azure Blueprints agrupa políticas e outras ferramentas de implementação num pacote repetível que pode atribuir a várias zonas de destino. Os esquemas são úteis para vários esforços de adoção que partilham DoDs comuns, que poderá querer atualizar ao longo do tempo. O Azure Blueprints também pode ajudar na implementação durante os esforços subsequentes para expandir e refatorizar zonas de destino.
O Azure Blueprints fornece vários exemplos de esquema, incluindo políticas para testes e modelos para implementação. Estes exemplos de esquema podem acelerar os esforços de desenvolvimento, implementação e teste em ciclos de TDD.
O Azure Resource Graph fornece uma linguagem de consulta para criar testes baseados em dados com base em informações sobre os recursos implementados numa zona de destino. Mais adiante no plano de adoção, esta ferramenta também pode definir testes complexos com base nas interações entre os recursos de carga de trabalho e o ambiente de cloud subjacente.
Resource Graph inclui exemplos de consultas avançadas, que pode utilizar para compreender como as cargas de trabalho são implementadas numa zona de destino para cenários de teste avançados.
Consoante a sua abordagem preferida, também pode utilizar as seguintes ferramentas:
- Implementar zonas de destino com o Terraform.
- Implementar zonas de destino com o Bicep.
- Faça a gestão de zonas de destino com o AzOps, um módulo do PowerShell que emite modelos de recursos e ficheiros Bicep em todos os níveis de âmbito do Azure e solicita e exporta hierarquias de recursos do Azure.