“Microservices = Multirepo”
Parece óbvio. Por que centralizar componentes cuja finalidade é a distribuição?
No entanto, esta é a escolha que Theodo teve de fazer para um dos seus clientes para poder continuar a desenvolver um produto em crescimento.
Darya Talanina compartilhou os motivos da migração de 30 microsserviços para um Monorepo durante uma edição da conferência Devoxx.
Este artigo compartilha sua história ilustrando as práticas e resultados obtidos sob o prisma do Quality Engineering.
Segue a QE Unit para mais conteúdos de Quality Engineering.
O projeto começa com um repositório por serviço
Algumas escolhas parecem naturais.
Neste caso, configura-se o de ter um repositório por projeto de back-end, voltado para um front-end.
A arquitetura Multirepo permanece facilmente compreensível.
O modelo de branching também é distribuído, com base em:
- Uma a várias ramificações de recursos por projeto
- Duas ramificações estáveis dedicadas aos ambientes “preprod” e “prod”
- Um processo de build por ordem de entrega.
Esse modelo permite que os desenvolvedores liberem recursos em seus próprios repositórios.
Os primeiros problemas começam a se materializar
É confortável desenvolver no seu canto, sem ter que sincronizar muito com o resto da equipe.
Azar, a colaboração é necessária para construir um produto devidamente organizado para satisfazer os utilizadores.
A primeira necessidade encontrada é centralizar regras comuns em um projeto comum, evitando assim a duplicação.
No papel, seguir o princípio de evitar a duplicação de código parece uma boa ideia.
As primeiras dores, no entanto, são sentidas pelos desenvolvedores, mesmo para fazer coisas simples.
Cada alteração de um componente referenciado envolve sua atualização nos diversos repositórios em questão.
Isso significa vários minutos sistematicamente perdidos, longe da criação de valor.
O crescimento do produto acelera o ponto de ruptura
Há boas notícias: o produto encontra seu mercado e requer mais desenvolvimento.
A arquitetura do projeto cresce de 11 a 31 microsserviços organizados no Multirepo no mesmo padrão tecnológico.
Por outro lado, a equipa começa a ficar saturado:
- O build inicial de 5 minutos deixando tempo para tomar um café agora leva até 2h30, o suficiente para ter uma overdose
- Alguns pull-requests são esquecidos nesse ecossistema distribuído, criando bugs regularmente na produção
- A implementação de práticas comuns requer 30 ações em diferentes repositórios, que ninguém quer realizar.
Darya resume claramente a situação.
O fluxo de trabalho pesado do git nos impede de melhorar a experiência do desenvolvedor e a qualidade do código.
Darya Talanina, Desenvolvedora Fullstack @ Theodo.
Além dos desenvolvedores, são os donos do produto e os clientes que estão ficando impacientes.
Todo esse tempo perdido em atualizações está longe de trazer o valor esperado na hora.
Os serviços são migrados de Multirepo para Monorepo
É tomada a decisão de mudar de Multirepo para Monorepo para todos os serviços de back-end.
A migração consiste em alternar os projetos um a um para o novo repositório centralizado.
Essa centralização também levanta a questão da construção e implantação quando mais alterações serão feitas na mesma base.
Um pipeline de integração contínua é configurado para fornecer feedback rapidamente sobre pushes de código.
O pipeline de integração contínua requer otimizações
A transição de um modelo descentralizado para um modelo centralizado não resolve o problema do tempo de construção do projeto.
O Monorepo apresenta o problema de saber quais projetos compilar durante uma mudança e quais fazer em paralelo.
A primeira solução é usar tags para especificar as atualizações de estruturação do repositório.
A explicação das dependências torna possível compilar apenas os projetos impactados por uma mudança
A paralelização é então cuidada pelo pipeline de integração contínua.
Os desenvolvedores podem finalmente entregar o valor esperado no prazo.
Quality at Speed torna-se acessível após a migração
O Monorepo contínua e pipeline possibilitam a entrega de mudanças em 10 minutos.
É o dia e a noite quando costumava levar horas.
A equipa ainda tem desafios a resolver: automação de testes e sua integração no pipeline, implantação progressiva, etc.
O importante é que até hoje a equipe seja capaz de entregar valor just in time com o mínimo de esforço.
O Quality Engineering não precisa ser complexo, deve restringir a cadeia de software ao Quality at Speed com o mínimo de Complexity.
Se calhar, precisa de um Monorepo?
Referências
Devoxx, Migrating 30 Microservices to a Monorepository https://www.softdevtube.com/2021/10/14/migrating-30-microservices-to-a-monorepository/
Siga Darya Talanina no GitHub e Twitter
Mais informações sobre Theodo.