De um certo tamanho da base de código, você ainda teria o Git ou existem soluções mais especializadas?
(Também para finalizar a compra apenas uma parte da base de código)
7
O Git funciona para monorepos, mas tem alguns problemas:
O Google, provavelmente o mais famoso usuário do monorepo, desenvolveu o Piper para atender às suas necessidades. Mas você não é o Google e, portanto, as soluções deles provavelmente não são suas.
Uma das principais vantagens de um monorepo é que você pode fazer alterações atômicas globalmente (ou seja, você não precisa fazer muitas versões porque pode alterar o chamador e o chamado na mesma confirmação). Para isso, você realmente deseja ter um sistema de compilação unificado que rastreie dependências em todo o repositório. O Bazel é uma extração de código aberto do sistema de compilação do Google, o Blaze, e tenta fazer isso (embora seja jovem e imaturo e sem muitos recursos necessários para o uso que não é do Google). Pants é um sistema semelhante fora do Twitter.
Se você estiver criando toneladas de código ao fazer uma alteração atômica, provavelmente também desejará um farm de construção que permita fazer isso não em sua máquina local. Da mesma forma, você precisará de um poderoso sistema de IC para lidar com a execução de testes em tudo o que atualizar.
A resposta é: um pouco de ambos. Para satisfazer as restrições de "use git" e "gerenciar uma vasta base de código", a Microsoft desenvolveu um novo sistema de arquivos (anteriormente eles estavam usando uma variante do Perforce chamada SourceDepot). É de código aberto, mas não tenho experiência pessoal em usá-lo.
Por que você quer um monorepo? O motivo mais óbvio é que você pode modificar uma API e todos os chamadores dessa API em uma confirmação atômica. Também existem vantagens em poder fazer uma git logpesquisa em toda a base de código ...
As opiniões divergem sobre o que é uma grande base de códigos. Se você está falando de uma empresa com 100 engenheiros, eu diria que o Git ainda poderá lidar com isso. Foi desenvolvido para as necessidades do kernel Linux, que não é um projeto pequeno por si só.
Independentemente da maneira como você armazena o repositório, você pode ter problemas. Por exemplo, se você estiver trabalhando em uma grande base de código Java e estiver usando ferramentas como Eclipse ou IntelliJ, elas usarão mais memória e geralmente ficarão mais lentas.
Por outro lado, ter a opção de operar todo o código de uma só vez (por exemplo, ao aplicar refatoração ou transformações de código-fonte) é uma das principais vantagens dos repositórios monolíticos.
Quando você pergunta se precisa de ferramentas especializadas e, em seguida, com um determinado tamanho de código, a resposta é sim. Segundo o Google, que provavelmente possui a maior base de código C ++ do mundo, todas as ferramentas disponíveis (código aberto ou comercial) não atendiam aos seus requisitos. Eles acabaram desenvolvendo um sistema interno chamado Piper:
Se eu entendi corretamente, a "necessidade" de um monorepo é simplesmente a necessidade fundamental de um esquema de versão único / coerente aplicado a um projeto de software que contém vários componentes / subprojetos vagamente relacionados que são / poderiam ser gerenciados / versionados independentemente em repositórios separados.
Semelhante, se você quiser, com a necessidade de usar um repositório de origem regular para fornecer um esquema de versão único / coerente para uma infinidade de arquivos de origem, cada um com seu próprio histórico de modificações independente.
Usar uma solução monorepo real é definitivamente uma, mas IMHO não é a única maneira de atender a essa necessidade.
Outra abordagem possível é usar um repositório de projeto abrangente contendo um ou mais arquivos de manifesto com a versão exata de cada um dos repositórios de componentes individuais do projeto.
Mesmo que os repositórios de componentes tenham suas versões modificadas por confirmações independentes e não atômicas, o próprio projeto pode ser gerenciado de forma coerente simplesmente combinando todas as alterações de versão do repositório de componentes relacionadas em uma única confirmação ao (s) arquivo (s) de manifesto no repositório guarda-chuva.
Essa abordagem tem várias vantagens sobre a migração para uma solução real de monorepo: