O Que é uma Polyrepo Architecture? Um Projeto Por Repositório
Uma polyrepo architecture dá a cada projeto, serviço ou library seu próprio repositório, história e pipeline separados.
O oposto de um monorepo, um setup polyrepo (ou multi-repo) divide o código para que cada serviço ou library viva em seu próprio repositório com seu próprio CI. É o encaixe natural para times e serviços totalmente independentes, mas empurra problemas de coordenação, código compartilhado, mudanças cross-cutting, version skew, para fora do repo onde o tooling não consegue mais vê-los atomicamente.
Um projeto, um repo
Cada componente tem seu próprio repositório, controle de acesso, história e pipeline. Código compartilhado é publicado como pacotes versionados dos quais outros repos dependem, em vez de referenciado diretamente como seria em um monorepo.
Por que times escolhem
- Isolamento forte e controle de acesso por repo.
- Cada repo tem uma pipeline pequena, focada e rápida.
- Times donos de seus repos e liberando na própria cadência.
- Sem uma história compartilhada gigante para clonar ou navegar.
O custo cross-repo
Uma mudança que abrange serviços agora abrange repositórios: múltiplos PRs, ordenação cuidadosa e nenhum commit atômico. Libraries compartilhadas precisam ser versionadas e publicadas, e o version skew, repos dependendo de versões diferentes, vira um fardo real de coordenação.
CI por repositório
Cada repo tem sua própria pipeline pequena e rápida, o que é simples em isolamento. A parte difícil é a integração: verificar que serviços buildados de forma independente ainda funcionam juntos, o que geralmente precisa de testes de integração cross-repo ou contract tests fora de qualquer pipeline única.
Coordenando releases
Como não há mudança cross-repo atômica, liberar uma feature que toca vários serviços significa sequenciar deploys e manter os contratos backward compatible. A disciplina que torna microservices seguros se aplica diretamente à coordenação polyrepo.
Muitas pipelines pequenas de uma vez
Um conjunto polyrepo significa muitas pipelines independentes disparando em paralelo entre os times. Fleets de runner gerenciados que escalam horizontalmente (como o Latchkey) evitam que todos esses builds concorrentes por repo enfileirem uns atrás dos outros.
Principais conclusões
- Uma polyrepo architecture dá a cada projeto seu próprio repositório e pipeline.
- Ela maximiza a independência por time ao custo de coordenação cross-repo.
- Código compartilhado e mudanças cross-cutting exigem versionamento e ordenação cuidadosa de release.