Microsserviços, gestão de processo ágil e testes de contrato com o framework PACT – Uma reflexão sobre as falhas no gerenciamento de processos

Testes
• 6 nov 2020

Este artigo faz parte de uma série, cujo tema principal é testes de contrato orientado a consumidor, Consumer-Driven Contract (CDC), com uso do framework PACT.

Para maiores detalhes sobre o PACT e CDC, confira os artigos:

Testes de contratos com PACT #1 – Conceitos.
Testes de contratos com PACT # 2 – Consumer-Driven Contract
Testes de contratos com PACT # 3 – Hands on

Trata-se de uma reflexão sobre as falhas de gestão de processos de desenvolvimento de software, principalmente em projetos com arquitetura de microsserviços ou SOA, e como testes de contratos (CDC) com uso do framework PACT podem auxiliar na correção dos problemas.

Microsserviços

Para as empresas alcançarem a necessidade constante de recursos de TI e melhorarem a agilidade, escalabilidade e resiliência, o caminho lógico é reduzir as aplicações em pedaços menores e executá-las de forma independente umas das outras. Eventualmente, elas serão pequenas o suficiente para serem microsserviços. A definição, segundo Martin Fowler, pode ser vista aqui.

Sob um olhar mais próximo sobre o conceito de microsserviços, fica claro que sua adoção vai muito além de quebrar aplicações em partes menores. Existem várias implicações na organização da empresa, times, processos e, principalmente, governança e gestão de projetos.

De forma geral, os benefícios da arquitetura de microsserviços os problemas resolvidos por ela são bem conhecidos. Porém, às vezes, seus pontos negativos não são tão claros, e acabam sendo negligenciados. Sistemas distribuídos são mais difíceis de programar, uma vez que chamadas remotas sempre possuem risco de falhas. Manter alta consistência é um desafio, tornando obrigatória a gestão de consistência eventual. A complexidade operacional aumenta drasticamente, requerendo processos maduros para gerenciar um número elevado de serviços que são publicados regularmente.

Como qualquer decisão arquitetural, o caminho a seguir envolve trocas. O pensamento “para toda conquista há uma perda” contextualiza muito bem a questão: é necessário estar preparado para lidar com as consequências da escolha. O principal erro está relacionado à gestão e a governança. Não é muito difícil encontrar projetos que estão perdidos em meio a um emaranhado de serviços e sem controle sobre as integrações. A solução para estes problemas requer práticas de gestão e governança, assunto abordado a seguir.

Governança

Governança é um conceito multidimensional, englobando elementos de administração organizacional, contabilidade, gestão de risco, conformidade (compliance), controle de propriedade, supervisão funcional e alocação de recursos. A governança é um conjunto de recursos de direcionamento, com base em três dimensões: planejar estrategicamente, estabelecer mecanismos para garantir o cumprimento dos planejamentos estratégicos, e também perceber e responder a mudanças.

Descentralização da Governança

Segundo Martin Fowler, uma das consequências da governança centralizada é a tendência de padronizar as plataformas em uma única tecnologia. Não é difícil perceber as limitações desta abordagem. Como diria Abraham Maslow, para quem sabe apenas usar um martelo, todo problema parece um prego.

A governança descentralizada fortalece a proposta de usar a ferramenta certa para a solução do problema. Desta forma, dividir os problemas em serviços independentes amplia a possibilidade de extrair o melhor de cada ferramenta ou tecnologia utilizada. Esta abordagem garante flexibilidade e, possivelmente, maior agilidade na resolução do problema. Não é difícil perceber que a governança descentralizada torna-se um caminho natural para projetos com arquitetura de microsserviços ou SOA.

Entretanto, esta abordagem pode gerar um distanciamento entre os times e serviços. Uma vez que são autônomos e independentes, a comunicação entre os times, em princípio, não é essencial para as atividades diárias. Porém, o que ocorre caso o serviço em desenvolvimento seja um requisito para o funcionamento de outros projetos? O que ocorre se a comunicação falhar?

Microsserviços, gestão de processo ágil e gerência de configuração

A gestão de mudanças em engenharia de software, normalmente chamada de gestão de configuração de software, prevê processos para planejar, implementar e avaliar mudanças de sistemas. Ela tem o objetivo de rastrear mudanças de artefatos, como código fonte e requisitos, dentre outros.

Todo projeto é um ser vivo que evolui e se transforma com o tempo. Desta forma, todos os envolvidos neste processo de transformação são responsáveis pela gerência de configuração em algum nível. Entretanto, funções especializadas às vezes são criadas para gerenciar a configuração de software. Quanto maior for a transformação, maior a possibilidade de confusão e erros.

Em práticas de gestão como COBIT, PMBOK e ITIL, é comum existir um papel responsável pela gerência de configuração. Contudo, quando o assunto é desenvolvimento ágil, independentemente da técnica ou método utilizado — SCRUM, Kanban, XP, híbrido —, existir um papel responsável pela gerência de configuração é algo incomum. A responsabilidade é compartilhada por todo o time. Em tese, pode ser algo muito positivo, uma vez que qualquer membro da equipe poderia cumprir a função. No entanto, na maioria das vezes, esse aspecto é negligenciado.

Nos eventos ou cerimônias de cada dia dos times, são abordados os assuntos que os impactam diretamente: as tarefas que foram desenvolvidas no dia anterior e que serão feitas no dia corrente, o que foi finalizado, impedimentos, mudanças de escopo e prioridades. Dificilmente no dia-a-dia os eventos abrem espaço para tratar de integrações com projetos de outros times.

Pense neste cenário: um novo requisito surge e uma alteração urgente precisa ser feita em uma API. Na reunião diária do time, os aspectos importantes são discutidos e o time começa a fazer as alterações. No final da tarde, o time executa a suíte de testes unitários e funcionais; tudo perfeito, tudo funcionando. O time dispara a esteira de deploy, aguarda o primeiro uso do novo recurso para fazer aquela última validação. Ufa, tudo perfeito, tudo funcionando. Após alguns minutos, outros projetos começam a apresentar problemas, você começa a perceber várias pessoas analisando logs, monitores de serviço. Em seguida, um grupo começa a perguntar sobre um deploy recente. O time confirma que foram os responsáveis pelo deploy e descobrem que a nova alteração na API quebrou o funcionamento em outros sistemas. Quem nunca presenciou uma cena parecida com essa, que jogue a primeira pedra.

Teste de contrato com PACT e CDC (Consumer-Driven Contracts)

De forma geral, testes de contrato validam a comunicação entre serviços, para garantir que mensagens possam ser enviadas por um provedor (provider) e lidas por um consumidor (consumer), sem a necessidade que o provedor e consumidor se comuniquem diretamente (teste de integração). Testes de contrato irão prevenir que APIs produzidas e consumidas quebrem seu funcionamento sem nenhuma ação manual, tornando o desenvolvimento e manutenção de funcionalidades mais simples e, principalmente, seguros.

Como funciona?

Um consumidor irá registrar suas expectativas sobre um serviço de um provedor em um contrato. Uma vez que o contrato tenha sido registrado, um teste irá validar se ambos, consumidor e provedor, estão em conformidade com esse contrato. Caso uma das partes viole o contrato, o teste será inválido. A proposta é adicionar o teste de contrato como requisito para execução do deploy, impedindo, desta forma, qualquer atualização que quebre o funcionamento das aplicações.

Figura 1 – Fluxo de ações do teste CDC do PACT.

Conclusão

A divisão dos problemas em partes menores facilita sua compreensão e simplifica a solução do problema. Mas, por outro lado, aumenta os desafios de integração. Gerenciar a integração entre projetos em um ecossistema de microsserviços ou SOA com um número elevado de serviços não é uma tarefa fácil. É preciso compreender as características e necessidades de cada projeto e time de desenvolvimento para fazer um diagnóstico preciso e certificar que as práticas de gestão adotadas, independentemente da abordagem ou método, estão dando a atenção devida às integrações dos projetos. Caso concluam que os esforços destinados à integração de projetos sejam insuficientes, provavelmente a adoção do PACT e CDC seja o que precisam para preencher a lacuna.

A proposta de adoção de testes de contratos não é nova. O PACT foi criado em 2013 por um time em realestate.com.au. Em 2015 e 2016, o CDC apareceu na publicação Technology Radar da ThoughtWorks. Apesar de não aparecer em versões posteriores da publicação, acredito que ainda seja de grande relevância, uma vez que arquiteturas de microsserviços e SOA continuam sendo amplamente adotadas pelas empresas. A implementação de testes com CDC e PACT pode ser o pilar para alcançar a maturidade e a independência da integração, alem da entrega contínua de projetos.

Além dos claros benefícios que podem ser obtidos, a adoção de testes de contrato não requer nenhum tipo ferramenta. Eles podem ser adicionados facilmente em qualquer projeto. Pela facilidade de adoção, todo projeto com arquitetura de microsserviços ou SOA deveria fazer a experiência e tirar suas próprias conclusões. Ouso acreditar que a maioria colherá bons frutos com a experiência.