Há um bom tempo que se houve falar sobre mono-repositório ou, para os mais íntimos, mono-repo. Essa abordagem de armazenamento de código consiste em ter um único repositório para todas as aplicações.

Embora possa parecer assustador – imagine todos os times da área de engenharia da sua empresa trabalhando em um mesmo repositório -, existem grandes benefícios em se optar por essa abordagem.

Nesse primeiro post sobre o mono-repo, trago as respostas para alguns questionamentos que ouço com frequência.

Fique tranquilo, as respostas que vou listar aqui não são meramente imaginativas, mas sim com base na experiência que tenho tido auxiliando na construção de um mono-repo.

Benefícios

Pensar em 30, 70, 200 ou até mais pessoas trabalhando em um mesmo repositório pode parecer caótico. No entanto, desde que feita organizadamente, os benefícios são muito grandes.

Qualidade de código

Ter todos os times trabalhando em um mono-repo, faz com que haja uma maior compatibilidade e padronização entre as aplicações.

Isso por que, além de um time conseguir utilizar o código do outro time como referência, muitos packages e classes serão compartilhados, fazendo com que os times sigam um padrão na hora de escrever código.

Além disso, é preciso formular regras para garantir que mudanças causem o mínimo impacto possível. Um exemplo seria X% de coverage mínimo para uma PR ser aceita.

Inner Source

Independente da linguagem que você trabalhe, com certeza é possível fazer classes ou packages reutilizáveis.

Num mono-repo, esses packages e classes são mais do que bem vindos. Afinal, a solução de um time pode acabar resolvendo o problema de N times sem que eles tenham que escrever uma linha de código.

Além disso, o inner source faz com que os times conversem e documentem mais, afinal, a mudança em package compartilhado pode afetar severamente outro time.

Padronização

É comum que os times trabalhem “no seu mundinho”, ou seja, criem seus vícios e padrões próprios. Isso é péssimo!

A falta de padronização entre aplicações, dificulta uma série de coisas, como a transição de pessoas entre times e criação de ferramentas para automação de pequenas tarefas.

Em um mono-repo, devido à força do inner source, a padronização acontece quase que naturalmente.

Manutenção

Sem sombra de dúvidas, manter a versão do Go e dos packages de terceiros atualizadas em um único repositório é muito mais fácil do que fazer o mesmo em N repositórios.

Embora isso possa parecer pequeno, é muito comum aplicações nascerem utilizando determinada versão do Go/dependências e nunca mais serem atualizadas. Isso faz com que a aplicação perca as atualizações de performance e segurança, podendo torná-la um risco para a organização.

Estando todo mundo em um único repositório, esse trabalho se torna mais fácil de executar.

Pipelines

Resvalando nos dois itens anteriores – padronização e manutenção -, ter um pipeline de Continuous Integration em múltiplos repositórios, com o tempo, faz com que cada projeto acabe tendo um fluxo diferente.

Já em um mono-repo, é possível ter um único pipeline de CI para todos os projetos. Isso garante que os mesmos passos para execução dos testes e builds, aconteçam da mesma forma para todos os projetos.

Outro ponto que vale destaque aqui é que, após criada, todo novo projeto acaba “ganhando” CI, ou seja, nenhum SRE ou DEV precisa investir tempo criando uma nova pipeline.

Fluxo de trabalho

Uma grande preocupação dos times de desenvolvimento, é sobre o que muda no fluxo de trabalho deles ao trabalhar em conjunto com outros times em um mono-repo.

A verdade é que, quando bem organizado, as mudanças nos fluxos de pull request, merge e release, não devem trazer grandes dores aos times.

Pull request

Para facilitar a reversão de código, é importante que, os pull requests sejam pequenos e sempre estejam atualizados com a última versão da branch principal.

Outro ponto importante, é não alterar código da aplicação e packages compartilhados em um mesmo pull request, já que fazer uma reversão de código aqui pode acabar impactando outros times.

Merge

Para facilitar o controle de entrada de código na branch principal, assim como change logs e reversão de código, é importante que todo merge seja efetuado com squash.

Dessa forma, cada PR acaba se tornando apenas um commit na branch principal, facilitando muito os processos citados anteriormente.

Release

Aqui é importante ter em mente que release é diferente de colocar a aplicação em produção.

O processo de release pode ser automatizado, onde é feito um release por dia do mono-repo todo, ou manual, onde o time escolhe quando fazer a release do projeto dele.

Ambas as abordagens são válidas, sendo a primeira muito mais simples que a segunda. No entanto, essa decisão deve ser tomada em conjunto pelos times que trabalharão no mono-repo.

4 Pilares

É claro que, para fazer tudo isso se tornar realidade, é preciso ter alguns cuidados. A meu ver, existem 4 pilares de sustentação para que um mono-repo dê certo.

Alinhamento

Seja sync ou async, é importante ter um canal, chamada e página de documentação para que todos os times tomem decisões juntos e estejam alinhados.

No início isso pode ser complexo de se fazer, devido as grandes decisões que precisam ser tomadas. No entanto, passado essa fase de decisões críticas, tudo tende a ter um fluxo mais tranquilo.

Testes

É muito importante ter alinhado entre todos os times que, nenhuma PR deve ser “mergeada” sem tem um mínimo de X% de cobertura de testes.

Isso deve ser um item INEGOCIÁVEL!!! Ter testes automatizadas ajudará todos, principalmente na hora de atualizar packages/classes comuns e executar manutenções no mono-repo.

Guardiões

Para que todos os processos de definições funcionem bem, é importante ter um grupo de pessoas como guardiões do mono-repo.

Esse grupo deve ser, na minha opinião, formada pelas pessoas com maior conhecimento e desejo de fazer o mono-repo ser uma realidade. Afinal, haverá momentos onde o único motivador para seguir enfrente será o desejo de ver acontecer.

Como objetivo, esse grupo de pessoas deve, além de zelar pelas boas práticas e cumprimento das regras estabelecidas, olhar para o futuro, evoluindo o mono-repo constantemente, a fim de tornar a vida de todos que trabalham nele mais fácil.

Comprometimento

Sem dúvida, esse é o principal pilar!

É preciso ter ao menos dois grupos de pessoas comprometidas em fazer o mono-repo se tornar realidade.

• Uma equipe, por menor que seja, para criar as automações e manter o mono-repo estável;
• Um time que tope ser early adopter, pois haverá muita dor no início.

Conclusão

Embora no começo as dores possam ser bem grandes e, em alguns casos, gerar algum entrave nas entregas, assim que essas dores iniciais forem sanadas, os benefícios compensarão.

No próximo post sobre mono-repo, trarei uma visão mais técnica do como fazer. Por isso, se inscreva na nossa newsletter para não perder nada!

Abraço e até a próxima!

Se inscreva na nossa newsletter