O Que é uma Monorepo Architecture? Muitos Projetos, Um Repositório
Uma monorepo architecture mantém muitos projetos, serviços ou libraries em um único repositório versionado com tooling e história compartilhados.
Um monorepo coloca tudo em um repositório: múltiplos serviços, libraries compartilhadas e tooling, todos versionados juntos. Não é o mesmo que um monolith (que é um único deployável); um monorepo pode conter muitos serviços deployáveis de forma independente. A escolha de arquitetura tem um efeito grande e direto em como o CI é estruturado, porque um CI ingênuo rebuildaria o mundo a cada mudança.
Um repo, muitos projetos
Múltiplos projetos compartilham um único repositório, uma história unificada e tooling comum. Uma mudança pode abranger vários projetos em um commit atômico, e libraries compartilhadas são usadas diretamente em vez de publicadas e versionadas entre repos.
Por que times escolhem
- Mudanças cross-project atômicas em um único commit.
- Um lugar para código, tooling e padrões compartilhados.
- Refactors em larga escala fáceis entre muitos projetos.
- Sem dança de version skew entre repos de dependência separados.
O desafio de CI
O problema de CI que define o monorepo são os builds seletivos: rebuildar e testar tudo a cada commit é desperdício e lento. Você precisa determinar quais projetos uma mudança afeta e buildar só esses, usando um build graph e detecção de mudanças.
Detecção de projetos afetados
Ferramentas de build de monorepo computam um grafo de dependências e, a partir dos arquivos alterados, derivam o conjunto de projetos afetados. A pipeline então builda e testa só esse conjunto. Acertar isso é o que mantém o CI de um grande monorepo rápido em vez de brutal.
Cache e paralelismo
Build caches remotos e paralelismo de tarefas são essenciais em escala: projetos não alterados reusam resultados em cache, e tarefas independentes rodam concorrentemente. Sem eles, o tempo de CI de monorepo cresce com o repo inteiro, não com a mudança.
Escalando o CI de monorepo
Builds seletivos mais cache e paralelismo mantêm as pipelines de monorepo rápidas, mas se apoiam fortemente em runners quentes e com cache. Os runners do Latchkey mantêm caches de dependência e de build quentes para que builds de projetos afetados reusem trabalho anterior em vez de começar frios.
Principais conclusões
- Uma monorepo architecture mantém muitos projetos em um repositório com tooling compartilhado.
- Não é um monolith; pode conter muitos serviços deployáveis de forma independente.
- Builds seletivos, cache e paralelismo são o que mantêm o CI de monorepo rápido.