Por que os testes devem mudar para a esquerda para microsserviços

Qual é a melhor maneira de liberar o código? Um processo sem picos, sem apagar incêndios, sem pressa desesperada para adicionar um recurso rápido para atender aos requisitos de um cliente corporativo? Quando tudo está dando certo, o processo fica assim:

Há uma década, os gerentes de projeto ridicularizavam as implementações em cascata do ciclo de vida de desenvolvimento de software (SDLC), onde as fases eram rigidamente definidas, o trabalho na fase de planejamento nunca se sobrepunha ao desenvolvimento e os testes começavam somente após o término do desenvolvimento. Esse processo fixo significava que os lançamentos eram pouco frequentes e demorava muito para obter feedback do usuário. As cascatas eram particularmente inadequadas para software entregue pela Internet, onde metodologias ágeis podiam lançar software diariamente e refletir o feedback do usuário em algumas semanas.

Embora as metodologias ágeis permitam que estas fases se sobreponham e enfatizem a velocidade de entrega, as fases ainda são baseadas em cascata e os métodos tradicionais de desenvolvimento, construção e teste não são adequados ao ambiente moderno baseado em microsserviços.

Dois grandes problemas com os testes hoje

Embora cada vez mais cargas de trabalho estejam migrando para microsserviços, os testes não conseguiram acompanhar as necessidades modernas de desenvolvimento. Aqui estão duas razões para isso.

Supõe-se que o controle de qualidade encontre regressões, não regresse à era da cachoeira

Embora as metodologias ágeis estejam intimamente associadas ao aumento da entrega de software online, outro componente que tornou as cascatas obsoletas foi a automação e a democratização da garantia de qualidade (QA). Com os testes automatizados e o controle de qualidade mais integrados às equipes de desenvolvimento, é incomum que os testes esperem que o desenvolvimento seja concluído. O processo moderno define muitas gradações finas de testes, desde testes unitários até testes ponta a ponta, com feedback constante à medida que os desenvolvedores escrevem código e conectam serviços.

Os microsserviços quebraram um pouco esse paradigma, reabrindo a porta para um mundo em cascata. Em termos gerais, a questão é a interdependência. Os microsserviços dependem tanto de outros serviços que é muito difícil obter uma imagem precisa dos testes antes que seu serviço seja implantado e interaja com nossos outros componentes e APIs de terceiros. Freqüentemente, uma equipe de controle de qualidade ou de operações é a primeira a encontrar problemas sérios com o código de microsserviços.

O resultado deste paradigma quebrado é que o feedback chega muito tarde no ciclo e requer uma liberação para as fases iniciais de desenvolvimento. Embora isso às vezes aconteça depois que o código está em produção, muitas vezes as implantações iniciais para testes não conseguem detectar problemas que aparecem em estágios posteriores, ou os testes canário finais encontram problemas de integração que deveriam ter aparecido muito antes no processo. O processo real é mais parecido com isto:

A solução mais comum oferecida para esses problemas é construir testes unitários, stubs e mocks para simular todos os outros componentes, mas essa estratégia raramente é totalmente bem-sucedida. Um conjunto de testes que pode simular um cluster complexo exige que o controle de qualidade seja altamente sofisticado com cada serviço na pilha ou que cada equipe esteja disposta a dedicar muito tempo para manter os testes em seu serviço e simulando com precisão os demais serviços.

O teste é muito lento para desenvolvedores

Ao tentar simular um cluster inteiro para teste, o resultado é inaceitavelmente lento. Como você precisa executar todo o conjunto de testes em um ambiente de teste, pode levar de 20 minutos a algumas horas para executar todos os testes e obter resultados. Mesmo 10 ou 20 minutos são longos o suficiente para que os desenvolvedores não fiquem sentados esperando que todos os testes sejam executados várias vezes durante o dia. É geralmente reconhecido que os desenvolvedores não executam testes de integração com frequência, onde o serviço atualizado funciona com o restante do cluster; em vez disso, eles esperam para executá-lo posteriormente no ciclo de vida da implantação.

Como muitos bugs são descobertos no final do ciclo de implantação, há outro problema de processo que lembra a época da cascata: quando um engenheiro de outra equipe descobre um bug, o processo de diagnóstico, relatório e correção do problema se torna complicado. Os engenheiros de operações e controle de qualidade têm a tarefa de preencher relatórios de bugs para cada problema de integração, e os desenvolvedores são solicitados a corrigir problemas fora da banda.

Mude para a esquerda para corrigir testes e desenvolvimento

Para corrigir o processo de desenvolvimento e teste de código, mude para a esquerda: teste o código no início do ciclo e forneça feedback diretamente aos desenvolvedores. Mudar para a esquerda é uma mudança cultural e prática, mas também inclui mudanças técnicas na forma como um ambiente de testes partilhado é configurado.

Faça alterações menores com mais frequência

Em um SDLC ideal para microsserviços, o foco está na integração de testes precoce e frequente, começando logo na fase de desenvolvimento. Essa abordagem enfatiza a importância de pequenas alterações incrementais no código. Ao manter o escopo das alterações limitado, os desenvolvedores podem compreender e testar mais facilmente o impacto de suas modificações. Essa granularidade não apenas acelera o processo de verificação, mas também torna os testes mais precisos.

Neste modelo, os desenvolvedores assumem a responsabilidade tanto pelo desenvolvimento quanto pelos testes de seu código. Esta apropriação esclarece responsabilidades e faz da qualidade uma prioridade desde o início. A abordagem é dimensionada de forma eficaz entre equipes de engenharia, já que cada equipe ou desenvolvedor pode trabalhar de forma independente em seus respectivos serviços ou recursos, reduzindo assim as dependências. Embora este seja um ótimo conselho, pode parecer difícil implementá-lo no ambiente de desenvolvimento atual: se o processo de liberação de código para um cluster de teste compartilhado levar muito tempo, não parece viável testar pequenas alterações incrementais. É melhor implementar um ambiente de teste compartilhado onde os desenvolvedores possam testar pequenas mudanças.

Obtenha feedback mais rápido

O ciclo de feedback neste modelo é rápido. Como os desenvolvedores testam à medida que avançam, muitos problemas potenciais são resolvidos imediatamente, muitas vezes antes de serem identificados como bugs no sentido tradicional. A diferença entre encontrar bugs como usuário e encontrá-los como desenvolvedor é enorme: quando um engenheiro de operações ou de confiabilidade do site (SRE) encontra um problema, ele precisa encontrar o engenheiro que lançou o código, descrever o problema que está vendo e apresentar algumas etapas para replicar o problema. Se, em vez disso, o desenvolvedor original encontrar o problema, ele poderá interromper todas essas etapas observando a saída, encontrando a causa e iniciando uma correção. Essa abordagem proativa à qualidade reduz o número de bugs que precisam ser registrados e resolvidos posteriormente no ciclo de desenvolvimento.

Culturalmente, este modelo SDLC promove uma cultura de CI/CD, onde as alterações de código são integradas, testadas e entregues de forma rápida e confiável. Isso não apenas acelera o processo de desenvolvimento, mas também melhora a qualidade geral do software. Embora CI signifique “integração contínua”, no contexto de microsserviços, as ferramentas de CI fornecem de maneira ideal testes contínuos para que os desenvolvedores conheçam antecipadamente os problemas do mundo real que enfrentarão ao tentar implantar código de microsserviços.

Espaço para Testes, com Integração

A integração de um sistema para visualizar alterações de código é um componente chave porque permite feedback imediato sobre como as alterações se comportarão em um ambiente ativo. Essas visualizações são inestimáveis ​​para desenvolvedores, bem como para outras partes interessadas, como gerentes de projeto e equipes de controle de qualidade. Os desafios técnicos são significativos e não existe uma solução imediata para criar uma cópia muito precisa da produção, onde cada desenvolvedor possa testar alterações frequentes.

Em resumo, os requisitos básicos para qualquer sistema desse tipo são:

• Uma cópia realista do ambiente de produção, com todas as dependências necessárias e os diversos microsserviços mantidos por outras equipes.
• Um caminho fácil para implantar novas e pequenas alterações de código neste ambiente compartilhado.
• Uma maneira de evitar colisões para que seu código experimental implantado em seu serviço não interrompa o desempenho do cluster de outro desenvolvedor.

Em geral, soluções que prometem manter uma cópia de todo o seu cluster apenas na hora de testar não são satisfatórias. Em vez disso, os desenvolvedores precisam fazer alterações pequenas e incrementais, às vezes implantando mais de uma vez por dia. O tempo que leva para levantar um cluster inteiro quando as coisas ficam realmente complexas desincentivará o objetivo de mudar para a esquerda.

Solicitar isolamento para deslocamento para a esquerda

Um ambiente de teste rápido e preciso para desenvolvedores deve ser nativo do espaço Kubernetes para permitir dinamicamente a atualização e o teste em um cluster compartilhado que usa os sistemas que executam ambientes de produção. Muitas equipes de grandes empresas implementaram um modelo chamado isolamento de solicitação, que permite que um serviço de teste seja executado como parte de um cluster sem interromper outros serviços. Equipes como Uber e DoorDash podem enviar uma versão de teste de um serviço, até mesmo para produção, que só lidará com solicitações de teste, mas ainda poderá fazer solicitações para todos os outros serviços dos quais depende.

Signadot permite que as equipes de desenvolvimento usem a técnica de isolamento de solicitação em seu cluster. Ao aproveitar uma malha de serviço, as equipes de engenharia podem direcionar apenas solicitações de teste para a versão atualizada do seu serviço. Quando um serviço é atualizado com uma versão de teste, a versão base do serviço permanece disponível para outras equipes, para que possam usar o mesmo cluster de teste.

O resultado permite que as equipes façam alterações pequenas e incrementais e as testem em um cluster real. Os próprios desenvolvedores encontram os problemas, diminuindo enormemente o tempo de feedback e acelerando o desenvolvimento.

A postagem Por que os testes devem mudar para a esquerda para microsserviços apareceu pela primeira vez em The New Stack.