Mudando o teste para a esquerda: a solução de isolamento de solicitação

Isso faz parte de uma série contínua. Leia as partes anteriores:

• Por que mudamos os testes para a esquerda: um ciclo de desenvolvimento de software que não pode ser escalonado
• Por que o teste de mudança foi deixado, parte 2: o controle de qualidade faz mais depois que os desenvolvedores executam os testes
• Como mudar os testes para a esquerda: 4 modelos táticos

Nas partes anteriores desta série, discutimos como o controle de qualidade tem uma função mesmo quando os testes mudam e como existem vários modelos para colocar testes mais precisos de volta nas mãos de desenvolvedores e engenheiros de desenvolvimento de software em teste (SDETs). Agora vamos considerar um modelo que seja eficaz à medida que as equipes vão além de uma única equipe de duas pizzas. Conceitualmente, os testes em um ambiente complexo de microsserviços devem incluir um ambiente compartilhado altamente preciso, onde os testes e experimentos dos desenvolvedores não interfiram nas atualizações de outros.

No parágrafo acima eu digo “de volta” às mãos dos desenvolvedores porque, antes da arquitetura de microsserviços e dos enormes clusters de contêineres, os desenvolvedores tinham o poder de executar testes em seu código que se assemelhavam muito a como seu código seria executado em produção.

Vamos discutir como essa abordagem funciona no nível arquitetônico.

Como aproveitar um cluster compartilhado para mudar o teste para a esquerda?

Em uma equipe pequena, um ambiente de teste compartilhado pode colocar testes reais nas mãos dos desenvolvedores. Com versões de teste de dependências de terceiros e cópias das versões de produção de todos os serviços internos, é uma ótima maneira para os desenvolvedores realizarem testes de pré-lançamento. Em equipes maiores, o problema essencial é que muitos desenvolvedores vão querer testar ao mesmo tempo. Quando o código de teste é enviado ao serviço A, a equipe que trabalha com o serviço B não consegue testar, para que seus testes falhem ou suas alterações interfiram nos testes do serviço A.

A solução é estabelecer um cluster altamente confiável para testes e, em seguida, permitir que as equipes implantem versões de teste de serviços que não afetem o cluster como um todo.

Fonte: Signadot

Alguns conceitos que usaremos ao longo desta explicação:

• Linha de base — A versão de base do cluster deve incluir serviços e recursos extremamente próximos do ambiente de produção implantado. As alterações precisam ser mescladas com a linha de base antes da implantação, garantindo que não haja grandes lacunas entre esse cluster e o produto. Essa linha de base normalmente é mantida atualizada com a ramificação principal/tronco usando pipelines de CI/CD.
• Caixa de areia — O serviço ou grupo de serviços nos quais os desenvolvedores estão testando. Em geral, isto envolverá uma nova versão de um serviço existente, mas uma sandbox também poderá conter novos serviços.

A ideia central é que, a cada solicitação entre serviços, precisamos decidir de forma inteligente se a solicitação deve ir para o serviço de linha de base ou para o sandbox. Essa solução é geralmente chamada de isolamento em nível de solicitação de serviços de teste/desenvolvimento.

O que precisamos para fazer o isolamento em nível de solicitação funcionar

O aumento técnico para o isolamento de solicitações não é zero e é importante identificar quais componentes precisam estar implementados para fazer o sistema funcionar:

• Solicitar roteamento — Também precisamos de algum sistema para encaminhar solicitações de maneira inteligente. Cada solicitação de serviço a serviço pode ser roteada para um serviço de destino diferente com base no valor de determinados cabeçalhos de solicitação.

Na Signadot, o roteamento de solicitações para sandboxes usa uma malha de serviço como o Istio ou sem malha de serviço, usando o método da Signadot DevMesh. Se estiver usando uma malha de serviço, o Signadot configura a malha para executar o roteamento de solicitações em seu nome sem a necessidade de componentes adicionais no cluster específicos para roteamento. O sidecar DevMesh é um proxy leve baseado em Envoy que pode ser adicionado a qualquer carga de trabalho por meio de uma anotação de pod do Kubernetes.

• Propagação de contexto — Finalmente, devemos ter um sistema para controlar se cada solicitação é uma solicitação de “teste” de um desenvolvedor que trabalha com uma sandbox. Como tal, é necessário um sistema para propagação de contexto com cabeçalhos consistentes.

Na Signadot, aproveitamos o poder do OpenTelemetry para fazer essa propagação de contexto. O componente “bagagem” do OpenTelemetry é perfeito para essa necessidade.

Histórias de sucesso com isolamento de solicitações

Muitas equipes, de nível médio a corporativo, solicitam isolamento de alguma forma para colocar o poder de testes altamente precisos nas mãos dos desenvolvedores. Aqui estão alguns exemplos.

Ambientes de teste de curta duração do Uber: sandboxes em um cluster compartilhado

Na Uber, as frustrações mencionadas em meus artigos anteriores com ambientes por desenvolvedor (requisitos desatualizados, atualizações lentas) levaram ao desenvolvimento de Ambientes de Teste de Aplicativos de Vida Curta (SLATE) que criaram sandboxes dentro de um cluster com up- versões atualizadas de serviços dependentes.

Fonte: Uber

O Uber vai um passo além do modelo que descrevi acima: em vez de ter tudo funcionando em um cluster de teste atualizado, os SLATEs também podem chamar serviços de produção conforme necessário. A equipe descreve os benefícios em sua postagem no blog:

“O SLATE melhorou significativamente a experiência e a velocidade dos testes E2E (ponta a ponta) para desenvolvedores. Isso permitiu que eles testassem suas alterações espalhadas por vários serviços e em relação às dependências de produção. Vários clientes, como dispositivos móveis, suítes de teste e scripts, podem ser usados ​​para testar serviços implantados no SLATE. Um ambiente SLATE pode ser criado sob demanda e recuperado quando não estiver em reutilização, resultando em usos eficientes da infraestrutura. Ao mesmo tempo que fornece tudo isso, ele impõe requisitos de isolamento e conformidade de dados.”

DoorDash obtém feedback 10 vezes mais rápido

Antes de implementar o isolamento de solicitações em um cluster compartilhado, os desenvolvedores do DoorDash estavam fazendo os testes finais em um ambiente de teste compartilhado. Os desenvolvedores foram forçados a usar simulações e testes de contrato para simular como as coisas funcionariam no teste, e essa replicação imperfeita fazia com que o teste falhasse frequentemente durante o teste de novos recursos.

Com o isolamento de solicitações, os desenvolvedores ainda usam o teste para testar seu trabalho, mas esses testes são isolados de outros, o que significa que não afetarão a estabilidade do teste para outros.

Usando o recurso de sandbox local do Signadot, os serviços que um desenvolvedor está experimentando podem ser executados em sua estação de trabalho local, enquanto todas as solicitações vão para o cluster compartilhado. Isso permite testes muito mais rápidos.

Os especialistas em experiência do desenvolvedor da DoorDash estimam que agora é 10 vezes mais rápido obter feedback do que usar um ambiente de teste compartilhado para testes finais.

Conclusões: de volta aos testes do desenvolvedor

Ao discutir a parte 1 desta série no Hacker News, um usuário respondeu com uma observação básica:

“Sempre que o código que você está desenvolvendo não puder ser correr sem algum computador mágico especial (que você não tem no momento), banco de dados mágico especial (que não está disponível no momento), carga de trabalho mágica especial (carga de produção, sim…), prevejo que o resultado será ruim. De uma forma ou de outra.”

Ironicamente, este é o estado do desenvolvimento de software moderno em clusters Kubernetes. O cluster não pode ser totalmente replicado localmente, então estamos fadados a uma replicação imperfeita e a simulações substituindo grandes pedaços de nossa pilha. Desde o nascimento das metodologias ágeis, esperamos que os desenvolvedores possam testar seu código quase instantaneamente.

Esta “mudança para a esquerda”, então, é verdadeiramente um retorno à forma. Com o isolamento de solicitações podemos permitir que os desenvolvedores façam o que sempre fizeram: experimentar, experimentar e descobrir o que funciona.

Junte-se à comunidade Signadot

Adoraríamos mostrar como o isolamento de solicitações funcionou para nossos usuários e explorar como a Signadot pode ajudá-lo. Confira signadot.com para mais histórias de usuários, tutoriais e práticas recomendadas.

A postagem Mudando o teste para a esquerda: a solução de isolamento de solicitação apareceu pela primeira vez em The New Stack.