O Que É um Monorepo?
Um monorepo armazena muitos projetos - apps, bibliotecas, serviços - em um único repositório com um histórico e um conjunto de tooling.
Em vez de um repositório por projeto, um monorepo mantém todos eles juntos. Isso torna as mudanças entre projetos atômicas e o tooling consistente, mas força o CI a ser inteligente sobre buildar apenas o que realmente mudou.
O que é um monorepo
Um único repositório versionado contendo múltiplos projetos distintos que compartilham dependências, configuração de build e histórico de commits. Grandes empresas e muitos ecossistemas open-source usam esse modelo.
O desafio do CI: builds afetados
Um pipeline ingênuo de monorepo rebuilda e retesta tudo a cada mudança - lento e desperdiçador. A solução é a detecção de mudanças: computar quais projetos um commit afeta e rodar o CI apenas para eles mais seus dependentes.
Um pequeno exemplo
Ferramentas como Nx ou Turborepo expõem um comando "affected" - nx affected --target=test roda testes apenas para os projetos tocados pelo diff e seus dependentes, de modo que uma mudança de uma linha em um pacote não reteste o repositório inteiro.
O caching importa mais
Como um build de monorepo toca muitos projetos, um remote build cache compartilhado tem um retorno desproporcional: projetos não alterados são restaurados do cache em vez de rebuildados, mantendo o tempo do pipeline proporcional à mudança, não ao repositório.
Trade-offs a ponderar
Monorepos dão mudanças atômicas entre projetos e tooling unificado, mas crescem muito, podem ter clones lentos e exigem detecção de mudanças disciplinada. O investimento em CI é maior, mas também o é o retorno em escala.
Principais conclusões
- Um monorepo mantém muitos projetos em um único repositório com tooling compartilhado.
- O CI precisa detectar os projetos afetados e buildar apenas eles mais os dependentes.
- Um remote cache compartilhado é especialmente valioso em um monorepo.