{"id":43993,"date":"2021-08-30T09:26:23","date_gmt":"2021-08-30T07:26:23","guid":{"rendered":"https:\/\/kinqsta.com\/?p=100242"},"modified":"2025-02-07T11:16:08","modified_gmt":"2025-02-07T14:16:08","slug":"monorepo-vs-multi-repo","status":"publish","type":"post","link":"https:\/\/kinqsta.com\/pt\/blog\/monorepo-vs-multi-repo\/","title":{"rendered":"Monorepo vs Multi-Repo: Vantagens e Desvantagens das Estrat\u00e9gias de Reposit\u00f3rio de C\u00f3digo"},"content":{"rendered":"

Existem duas estrat\u00e9gias principais para hospedar<\/a> e gerenciar c\u00f3digo atrav\u00e9s do Git: monorepo vs multi-repo. Ambas as abordagens t\u00eam os seus pr\u00f3s e os seus contras.<\/p>\n

Podemos usar qualquer abordagem para qualquer base de c\u00f3digo em qualquer linguagem. Voc\u00ea pode usar qualquer uma destas estrat\u00e9gias para projetos que contenham um punhado de bibliotecas<\/a> para milhares delas. Mesmo se envolver alguns membros da equipe ou centenas, ou se voc\u00ea quiser hospedar c\u00f3digo privado ou de c\u00f3digo aberto, voc\u00ea ainda pode ir com monorepo ou multi-repo com base em v\u00e1rios fatores.<\/p>\n

Quais s\u00e3o os benef\u00edcios e inconvenientes de cada abordagem? Quando devemos usar uma ou a outra? Vamos descobrir!<\/p>\n

<\/div><\/kinsta-auto-toc>\n

O que s\u00e3o Repos?<\/h2>\n

Um repo (abrevia\u00e7\u00e3o para reposit\u00f3rio) \u00e9 um armazenamento para todas as altera\u00e7\u00f5es e arquivos de um projeto, permitindo aos desenvolvedores “controlar a vers\u00e3o” dos ativos do projeto ao longo de sua fase de desenvolvimento.<\/p>\n

Normalmente nos referimos aos reposit\u00f3rios Git<\/a> (como fornecidos pelo GitHub<\/a>, GitLab<\/a> ou Bitbucket<\/a>), mas o conceito tamb\u00e9m se aplica a outros sistemas de controle de vers\u00e3o (como o Mercurial).<\/p>\n\n

O que \u00e9 Monorepo?<\/h2>\n

A abordagem monorepo utiliza um \u00fanico reposit\u00f3rio<\/a> para hospedar todo o c\u00f3digo das m\u00faltiplas bibliotecas ou servi\u00e7os que comp\u00f5em os projetos de uma empresa. No seu extremo, toda a base de c\u00f3digo de uma empresa – abrangendo v\u00e1rios projetos e codificados em diferentes linguagens – \u00e9 hospedada em um \u00fanico reposit\u00f3rio.<\/p>\n

Benef\u00edcios do Monorepo<\/h2>\n

Hospedar toda a base de c\u00f3digo em um \u00fanico reposit\u00f3rio oferece os seguintes benef\u00edcios.<\/p>\n

Barreiras de entrada mais baixas<\/h3>\n

Quando os novos funcion\u00e1rios come\u00e7am a trabalhar para uma empresa, eles precisam baixar o c\u00f3digo e instalar as ferramentas necess\u00e1rias para come\u00e7ar a trabalhar em suas tarefas. Suponha que o projeto esteja disperso por muitos reposit\u00f3rios, cada um tendo suas instru\u00e7\u00f5es de instala\u00e7\u00e3o e ferramentas necess\u00e1rias. Nesse caso, a instala\u00e7\u00e3o inicial ser\u00e1 complexa e, na maioria das vezes, a documenta\u00e7\u00e3o n\u00e3o estar\u00e1 completa, exigindo que esses novos membros da equipe procurem os colegas para obter ajuda.<\/p>\n

Um monorepo simplifica as coisas. Como h\u00e1 um \u00fanico local contendo todo o c\u00f3digo e documenta\u00e7\u00e3o<\/a>, voc\u00ea pode agilizar a configura\u00e7\u00e3o inicial.<\/p>\n

Gest\u00e3o de c\u00f3digos de localiza\u00e7\u00e3o central<\/h3>\n

Ter um \u00fanico reposit\u00f3rio d\u00e1 visibilidade de todo o c\u00f3digo a todos os desenvolvedores. Ele simplifica o gerenciamento do c\u00f3digo, uma vez que podemos usar um \u00fanico rastreador de problemas para observar todos os problemas ao longo do ciclo de vida do aplicaivo.<\/p>\n

Por exemplo, estas caracter\u00edsticas s\u00e3o valiosas quando um problema abrange duas (ou mais) bibliotecas infantis com o bug existente na biblioteca dependente. Com v\u00e1rios reposit\u00f3rios, pode ser um desafio encontrar o peda\u00e7o de c\u00f3digo<\/a> onde o problema acontece.<\/p>\n

Al\u00e9m disso, precisar\u00edamos descobrir qual reposit\u00f3rio usar para criar o problema e, em seguida, convidar e cruzar os membros de outras equipes para ajudar a resolver o problema.<\/p>\n

Com um monorepo, por\u00e9m, tanto a localiza\u00e7\u00e3o de problemas de c\u00f3digo como a colabora\u00e7\u00e3o para solucionar problemas tornam-se mais simples de alcan\u00e7ar.<\/p>\n

Refatora\u00e7\u00f5es para aplicativo sem dor<\/h3>\n

Ao criar uma refatora\u00e7\u00e3o do c\u00f3digo em toda o aplicaivo, v\u00e1rias bibliotecas ser\u00e3o afetadas. Se voc\u00ea estiver hospedando-as atrav\u00e9s de m\u00faltiplos reposit\u00f3rios, gerenciar todos os diferentes pedidos pull para mant\u00ea-las sincronizadas umas com as outras pode se revelar um desafio.<\/p>\n

Um monorepo facilita a realiza\u00e7\u00e3o de todas as modifica\u00e7\u00f5es em todos os c\u00f3digos para todas as bibliotecas e o envio sob um \u00fanico pedido de puxar.<\/p>\n

Funcionalidade adjacente mais dif\u00edcil de ser quebrada<\/h3>\n

Com o monorepo, podemos configurar todos os testes para que todas as bibliotecas funcionem sempre que uma \u00fanica biblioteca for modificada. Como resultado, a probabilidade de fazer uma altera\u00e7\u00e3o em algumas bibliotecas minimizou os efeitos adversos em outras bibliotecas.<\/p>\n

As equipes compartilham uma cultura de desenvolvimento<\/h3>\n

Ainda que n\u00e3o imposs\u00edvel, com uma abordagem monorepo, torna-se um desafio inspirar subculturas \u00fanicas entre diferentes equipes. Uma vez que partilhar\u00e3o o mesmo reposit\u00f3rio, muito provavelmente partilhar\u00e3o as mesmas metodologias de programa\u00e7\u00e3o<\/a> e gest\u00e3o e utilizar\u00e3o as mesmas ferramentas de desenvolvimento<\/a>.<\/p>\n

Problemas com a Abordagem Monorepo<\/h2>\n

Usar um \u00fanico reposit\u00f3rio para todos os nossos c\u00f3digos tem v\u00e1rios inconvenientes.<\/p>\n

Ciclos de desenvolvimento mais lentos<\/h3>\n

Quando o c\u00f3digo de uma biblioteca cont\u00e9m altera\u00e7\u00f5es de quebra, que fazem com que os testes para bibliotecas dependentes falhem, o c\u00f3digo tamb\u00e9m deve ser corrigido antes de fundir as altera\u00e7\u00f5es.<\/p>\n

Se essas bibliotecas dependem de outras equipes, que est\u00e3o ocupadas trabalhando em alguma outra tarefa e n\u00e3o conseguem (ou n\u00e3o querem) adaptar seu c\u00f3digo para evitar as mudan\u00e7as de quebra e ter os testes aprovados, o desenvolvimento da nova funcionalidade pode parar.<\/p>\n

Al\u00e9m disso, o projeto pode muito bem come\u00e7ar a avan\u00e7ar apenas com a velocidade da equipe mais lenta da empresa. Esse resultado pode frustrar os membros das equipes mais r\u00e1pidas, criando condi\u00e7\u00f5es para que eles queiram deixar a empresa.<\/p>\n

Al\u00e9m disso, uma biblioteca precisar\u00e1 executar os testes para todas as outras bibliotecas tamb\u00e9m. Quanto mais testes forem feitos<\/a>, mais tempo leva para execut\u00e1-los, diminuindo a velocidade com que podemos iterar o nosso c\u00f3digo.<\/p>\n

Requer download do codebase completo<\/h3>\n

Quando o monorepo cont\u00e9m todo o c\u00f3digo de uma empresa, ele pode ser enorme, contendo gigabytes de dados. Para contribuir com qualquer biblioteca hospedada dentro, qualquer pessoa precisaria de um download de todo o reposit\u00f3rio.<\/p>\n

Lidar com uma vasta base de c\u00f3digo implica um mau uso do espa\u00e7o nos nossos discos r\u00edgidos e uma interac\u00e7\u00e3o mais lenta com ele. Por exemplo, a\u00e7\u00f5es cotidianas como executar o git status<\/code> ou procurar na base de c\u00f3digo com um regex podem levar muitos segundos ou at\u00e9 minutos mais do que levariam com m\u00faltiplos reposit\u00f3rios.<\/p>\n

Bibliotecas n\u00e3o modificadas podem ser rec\u00e9m-criadas<\/h3>\n

Quando etiquetamos<\/a> o monorepo, todo o c\u00f3digo dentro dele \u00e9 atribu\u00eddo \u00e0 nova etiqueta. Se esta a\u00e7\u00e3o desencadear um novo lan\u00e7amento, ent\u00e3o todas as bibliotecas hospedadas no reposit\u00f3rio ser\u00e3o lan\u00e7adas novamente com o n\u00famero da vers\u00e3o da tag, mesmo que muitas dessas bibliotecas possam n\u00e3o ter tido nenhuma altera\u00e7\u00e3o.<\/p>\n

O forking \u00e9 mais dif\u00edcil<\/h3>\n

Os projetos de c\u00f3digo aberto devem facilitar ao m\u00e1ximo o envolvimento dos colaboradores. Com v\u00e1rios reposit\u00f3rios, os contribuidores podem ir diretamente para o reposit\u00f3rio espec\u00edfico do projeto para o qual eles querem contribuir. Com um monorepo hospedando v\u00e1rios projetos, no entanto, os contribuidores devem primeiro navegar para o projeto certo e ter\u00e3o que entender como sua contribui\u00e7\u00e3o pode afetar todos os outros projetos.<\/p>\n

O que \u00e9 o Multi-Repo?<\/h2>\n

A abordagem multi-repo utiliza v\u00e1rios reposit\u00f3rios para hospedar as m\u00faltiplas bibliotecas ou servi\u00e7os de um projeto desenvolvido por uma empresa. No seu extremo, ele ir\u00e1 hospedar cada conjunto m\u00ednimo de c\u00f3digo reutiliz\u00e1vel ou funcionalidade aut\u00f4noma (como um microservi\u00e7o) sob seu reposit\u00f3rio.<\/p>\n

Benef\u00edcios do Multi-Repo<\/h2>\n

Hospedar cada biblioteca independentemente de todas as outras proporciona uma infinidade de benef\u00edcios.<\/p>\n

Vers\u00e3o de biblioteca independente<\/h3>\n

Ao etiquetar um reposit\u00f3rio, toda a sua base de c\u00f3digos \u00e9 atribu\u00edda \u00e0 etiqueta “novo”. Como apenas o c\u00f3digo de uma biblioteca espec\u00edfica est\u00e1 no reposit\u00f3rio, a biblioteca pode ser etiquetada e versionada independentemente de todas as outras bibliotecas hospedadas em outro lugar.<\/p>\n

Ter uma vers\u00e3o independente para cada biblioteca ajuda a definir a \u00e1rvore de depend\u00eancias do aplicaivo, permitindo-nos configurar qual a vers\u00e3o de cada biblioteca a utilizar.<\/p>\n

Lan\u00e7amentos de servi\u00e7os independentes<\/h3>\n

Como o reposit\u00f3rio cont\u00e9m apenas o c\u00f3digo para algum servi\u00e7o e nada mais, ele pode ter seu pr\u00f3prio ciclo de implanta\u00e7\u00e3o, independentemente de qualquer progresso feito nas aplica\u00e7\u00f5es que o acessam.<\/p>\n

O servi\u00e7o pode usar um ciclo de libera\u00e7\u00e3o r\u00e1pida, como a entrega cont\u00ednua (onde o novo c\u00f3digo \u00e9 implantado ap\u00f3s passar todos os testes). Algumas bibliotecas que acessam o servi\u00e7o podem usar um ciclo de libera\u00e7\u00e3o mais lento, como aquelas que s\u00f3 produzem uma nova libera\u00e7\u00e3o uma vez por semana.<\/p>\n

Ajuda a definir o controle de acesso em toda a organiza\u00e7\u00e3o<\/h3>\n

Apenas os membros da equipe envolvidos no desenvolvimento de uma biblioteca precisam ser adicionados ao reposit\u00f3rio correspondente e baixar seu c\u00f3digo. Como resultado, h\u00e1 uma estrat\u00e9gia impl\u00edcita de controle de acesso para cada camada do aplicativo<\/a>. Aos envolvidos com a biblioteca ser\u00e3o concedidos direitos de edi\u00e7\u00e3o, e todos os outros poder\u00e3o n\u00e3o ter acesso ao reposit\u00f3rio. Ou podem receber direitos de leitura, mas n\u00e3o de edi\u00e7\u00e3o.<\/p>\n

Permite que as equipes trabalhem de forma aut\u00f3noma<\/h3>\n

Os membros da equipe podem projetar a arquitetura da biblioteca e implementar seu c\u00f3digo trabalhando de forma isolada de todas as outras equipes. Eles podem tomar decis\u00f5es baseadas no que a biblioteca faz no contexto geral, sem serem afetados pelos requisitos espec\u00edficos de alguma equipe ou aplicaivo externa.<\/p>\n

Problemas com a abordagem Multi-Repo<\/h2>\n

O uso de m\u00faltiplos reposit\u00f3rios pode dar origem a v\u00e1rios problemas.<\/p>\n

As bibliotecas devem ser constantemente renovadas<\/h3>\n

Quando uma nova vers\u00e3o de uma biblioteca contendo altera\u00e7\u00f5es de quebra \u00e9 lan\u00e7ada, as bibliotecas que dependem desta biblioteca precisar\u00e3o ser adaptadas para come\u00e7ar a usar a vers\u00e3o mais recente. Se o ciclo de lan\u00e7amento da biblioteca for mais r\u00e1pido que o das bibliotecas dependentes, elas poder\u00e3o ficar rapidamente fora de sincronia entre si.<\/p>\n

As equipes ter\u00e3o de estar constantemente em dia para utilizar os \u00faltimos lan\u00e7amentos de outras equipes. Dado que equipes diferentes t\u00eam prioridades diferentes, isto pode por vezes revelar-se dif\u00edcil de alcan\u00e7ar.<\/p>\n

Consequentemente, uma equipe que n\u00e3o consiga recuperar o atraso pode acabar por se agarrar \u00e0 vers\u00e3o desatualizada da biblioteca dependente. Este resultado ter\u00e1 implica\u00e7\u00f5es no aplicaivo (em termos de seguran\u00e7a, velocidade e outras considera\u00e7\u00f5es), e a lacuna no desenvolvimento entre bibliotecas pode ser apenas maior.<\/p>\n

Podem fragmentar as equipes<\/h3>\n

Quando equipes diferentes n\u00e3o precisam interagir umas com as outras, elas acabam trabalhando em seus pr\u00f3prios silos. A longo prazo, isto poderia levar a equipes gerando subculturas comerciais, tais como o uso de diferentes metodologias de programa\u00e7\u00e3o ou gerenciamento, ou o uso de diferentes conjuntos de ferramentas de desenvolvimento.<\/p>\n

Se algum membro da equipe eventualmente precisar trabalhar em uma equipe diferente, ele pode sofrer um pouco de choque cultural e aprender uma nova maneira de fazer seu trabalho.<\/p>\n

Monorepo vs Multi-Repo: Principais diferen\u00e7as<\/h2>\n

Ambas as abordagens acabam por lidar com o mesmo objetivo: gerir a base de c\u00f3digos. Assim, ambas devem resolver os mesmos desafios, incluindo a gest\u00e3o de vers\u00f5es, fomentando a colabora\u00e7\u00e3 o entre os membros da equipe<\/a>, tratando de problemas, realizando testes, entre outros.<\/p>\n

A sua principal diferen\u00e7a diz respeito ao momento em que os membros da equipe tomam as suas decis\u00f5es: ou antecipadamente, para o monorepo, ou ao final da linha, para o multi-repo.<\/p>\n

Vamos analisar esta ideia com mais detalhe.<\/p>\n

Como todas as bibliotecas s\u00e3o versionadas independentemente no multi-reportagem, uma equipe que lan\u00e7a uma biblioteca com mudan\u00e7as de quebra pode faz\u00ea-lo com seguran\u00e7a, atribuindo um novo n\u00famero de vers\u00e3o principal ao \u00faltimo lan\u00e7amento. Outros grupos podem ter suas bibliotecas dependentes grudadas na vers\u00e3o antiga e mudar para a nova, uma vez que seu c\u00f3digo tenha sido adaptado.<\/p>\n

Esta abordagem deixa a decis\u00e3o de quando adaptar todas as outras bibliotecas a cada equipe respons\u00e1vel, que pode fazer isso a qualquer momento. Se o fizerem demasiado tarde e forem lan\u00e7adas novas vers\u00f5es de bibliotecas, fechar a lacuna entre bibliotecas tornar-se-\u00e1 cada vez mais dif\u00edcil.<\/p>\n

Consequentemente, enquanto uma equipe pode iterar rapidamente e frequentemente no seu c\u00f3digo, outras equipes podem revelar-se incapazes de recuperar o atraso, acabando por produzir bibliotecas que divergem.<\/p>\n

Por outro lado, em um ambiente monorepo, n\u00e3o podemos lan\u00e7ar uma nova vers\u00e3o de uma biblioteca que quebra alguma outra biblioteca, uma vez que seus testes ser\u00e3o reprovados. Neste caso, a primeira equipe deve comunicar com a segunda equipe para incorporar as altera\u00e7\u00f5es.<\/p>\n

Esta abordagem for\u00e7a as equipes a adaptar todas as bibliotecas no<\/a> seu conjunto sempre que uma mudan\u00e7a para uma \u00fanica biblioteca tem de acontecer. Todas as equipes s\u00e3o for\u00e7adas a falar umas com as outras e a chegar a uma solu\u00e7\u00e3o em conjunto.<\/p>\n

Como resultado, a primeira equipe n\u00e3o ser\u00e1 capaz de iterar t\u00e3o r\u00e1pido quanto deseja, mas o c\u00f3digo entre diferentes bibliotecas n\u00e3o come\u00e7ar\u00e1 a divergir em nenhum momento.<\/p>\n

Em resumo, a abordagem multi-repo pode ajudar a criar uma cultura de “avan\u00e7ar r\u00e1pido e quebrar coisas” entre as equipes, onde equipes \u00e1geis e independentes podem produzir a sua produ\u00e7\u00e3o \u00e0 sua velocidade. Em vez disso, a abordagem monorepo favorece uma cultura de consci\u00eancia e cuidado, onde as equipes n\u00e3o devem ser deixadas para tr\u00e1s para lidar com um problema sozinhas.<\/p>\n

Abordagem h\u00edbrida Poly-As-Mono<\/h2>\n

Se n\u00e3o podemos decidir se usamos as abordagens multi-repo ou monorepo, h\u00e1 tamb\u00e9m a abordagem intermedi\u00e1ria: usar m\u00faltiplos reposit\u00f3rios e empregar alguma ferramenta para mant\u00ea-los sincronizados, tornando-o parecido com um monorepo, mas com mais flexibilidade.<\/p>\n

Meta<\/a> \u00e9 uma dessas ferramentas. Ele organiza m\u00faltiplos reposit\u00f3rios sob subdiret\u00f3rios e fornece uma interface de linha de comando<\/a> que executa o mesmo comando em todos eles simultaneamente.<\/p>\n

Um meta-reposit\u00f3rio cont\u00e9m as informa\u00e7\u00f5es sobre os reposit\u00f3rios que comp\u00f5em um projeto. Clonando esse reposit\u00f3rio via meta, todos os reposit\u00f3rios necess\u00e1rios ser\u00e3o clonados recursivamente, facilitando aos novos membros da equipe a come\u00e7ar a trabalhar em seus projetos imediatamente.<\/p>\n

Para clonar um meta-reposit\u00f3rio e todos os seus m\u00faltiplos reposit\u00f3rios definidos, devemos executar o seguinte:<\/p>\n

meta git clone [meta repo url]\n<\/code><\/pre>\n
Meta ir\u00e1 executar um git clone<\/code>\u00a0para cada reposit\u00f3rio e coloc\u00e1-lo em uma subpasta:<\/p>\n
\"Clonando<\/a>
Clonando um meta-projecto. (Fonte da imagem: github.com\/mateodelnorte\/meta<\/a>)<\/figcaption><\/figure>\n
A partir da\u00ed, a execu\u00e7\u00e3o do comando de meta exec<\/code> executar\u00e1 o comando em cada subpasta. Por exemplo, executar o\u00a0git checkout master<\/code> em cada reposit\u00f3rio \u00e9 feito desta forma:<\/p>\n
meta exec \"git checkout master\"\n<\/code><\/pre>\n
Abordagem h\u00edbrida Mono-As-Poly<\/h2>\n
Outra abordagem \u00e9 gerenciar o c\u00f3digo atrav\u00e9s de um monorepo para desenvolvimento, mas copiando o c\u00f3digo de cada biblioteca em seu reposit\u00f3rio independente para implanta\u00e7\u00e3o.<\/p>\n
Esta estrat\u00e9gia \u00e9 predominante dentro do ecossistema PHP porque o Packagist<\/a> (o reposit\u00f3rio principal do Composer<\/a>) requer uma URL <\/a>de reposit\u00f3rio p\u00fablico para publicar um pacote, e n\u00e3o \u00e9 poss\u00edvel indicar que o pacote est\u00e1 localizado dentro de um subdiret\u00f3rio do reposit\u00f3rio.<\/p>\n
Dada a limita\u00e7\u00e3o do Packagist, os projetos PHP ainda podem usar um monorepo para desenvolvimento<\/a>, mas eles devem usar a abordagem multi-repo para implanta\u00e7\u00e3o.<\/p>\n
Para conseguir esta convers\u00e3o, podemos executar um script com<\/a> git subtree split<\/code><\/a> Ou usar uma das ferramentas dispon\u00edveis que executam a mesma l\u00f3gica:<\/p>\n