Você deve usar um Monorepo?

Shutterstock / Andrey Suslov

O padrão monorepo usa um único repositório de controle de versão para todos os seus projetos e ativos. Você agrupará seus arquivos de configuração de servidor, front-end e infraestrutura em um repositório para o qual todos contribuem. Você deve usá-lo?

O padrão é popular entre grandes empresas de tecnologia. Google, Microsoft e Facebook estão entre as organizações que usam monorepos. O que torna um monorepo tão atraente?

A alternativa

O Monorepo se opõe ao multi-repo. O padrão multi-repo permite que você crie um novo repositório para cada um de seus projetos. Normalmente é bastante claro quando um projeto merece seu próprio repositório.

Se você estiver criando um aplicativo, poderá ter três repositórios:

• Código do lado do servidor: sua API (possivelmente com repositórios adicionais para esquemas de banco de dados e documentação).
• Projeto Android: compilação Android do seu aplicativo, usando Java ou Kotlin.
• Projeto iOS: Objective-C ou Swift para seu aplicativo iOS.

Aqui, tudo o que compõe sua empresa é dividido em unidades distintas de funcionalidade. Com um monorepo, você abandona esse agrupamento e sempre assume a visão agregada. Todos os seus ativos pertencem um ao outro e têm a versão adequada.

Colaboração

Um dos benefícios monorepo mais citados diz respeito à colaboração. Em um monorepo, todo mundo vê tudo. Isso ajuda a clareza, facilita a abertura e torna mais simples para pessoas em equipes diferentes acessarem umas às outras &’ trabalho.

As pessoas podem trabalhar juntas com mais facilidade em uma tarefa, mesmo que esteja fora de suas responsabilidades habituais. Em um cenário multi-repo, pode ser necessário solicitar acesso ao repositório relevante primeiro. Isso aumenta a fricção que a abordagem monorepo evita totalmente.

Os monorepos encorajam todos a manter a propriedade do objetivo final, em vez das partes individuais que o compõem. Isso pode fazer com que as pessoas se sintam mais envolvidas e mais bem informadas sobre o que está acontecendo. Um desenvolvedor de aplicativo pode nunca tocar nos componentes do servidor, mas eles podem “ sentir ” evoluindo junto com seu próprio trabalho.

Facilidade de abstração

Monorepos também simplificam a abstração do código. É comum acabar com uma funcionalidade semelhante em seu back-end e componentes de front-end. Faz sentido abstrair isso em uma biblioteca compartilhada.

No paradigma multi-repo, você &’ d precisa criar um novo repositório e, em seguida, referenciá-lo nos outros. Isso pode ser construindo um pacote ou usando submódulos Git. De qualquer forma, muito trabalho é necessário antes que seu código abstraído possa ser realimentado nos projetos de onde foi originado.

O processo é mais simples se você tiver um monorepo. Você pode mover o código para um diretório que faça sentido e, em seguida, importá-lo para onde for necessário. Uma “ abstração ” leva alguns segundos. Há uma conveniência semelhante quando é hora de documentar o código: você pode adicionar os documentos ao seu sistema de documentação compartilhado.

Multi-repos também apresentam obstáculos práticos ao abstrair o código. Um membro da equipe de desenvolvimento geralmente não tem as permissões necessárias do GitLab, GitHub ou Bitbucket para criar um novo repositório. Isso resulta em sobrecargas ainda maiores quando um líder de equipe deve aprovar a nova biblioteca e configurar um repositório. Monorepos ajudam desenvolvedores individuais a criar código reutilizável, eliminando processos de abstração especiais.

Além de criar a abstração, os monorepos simplificam a manutenção de módulos compartilhados. Você não precisa atualizar cada consumidor de um pacote sempre que atualizá-lo. Todas as dependências existem na mesma base de código, então você pode referenciá-las sem um gerenciador de pacotes ou controle de versão dedicado.

Velocidade de desenvolvimento

Usar um monorepo pode acelerar a velocidade de desenvolvimento. Já tocamos nisso nas seções anteriores, mas vale a pena prestar mais atenção.

Monorepos reduzem as ações duplicadas. Se você precisar refatorar, é um único Find and Replace para aplicar a alteração em toda a base de código. Há menos alternância entre projetos e menos solicitações de pull para revisão.

Os colaboradores têm mais capacidade de autosserviço. Como as informações não são armazenadas em repositórios de equipe, as pessoas estão mais bem equipadas para procurar os detalhes de que precisam. Isso pode reduzir o vaivém durante o planejamento e a revisão do código.

Essas características também ajudam quando você está refatorando um sistema existente. Tentando quebrar um aplicativo legado em seu “ front-end ” e “ back-end ” pode ser a abordagem errada. Mudanças em um lado inevitavelmente impactarão o outro, então você estará reconciliando continuamente os dois repositórios. Usar um monorepo ajuda a refatorar rapidamente grandes faixas da base de código, sabendo que você está impactando todo o sistema, em vez de componentes fragmentados.

Para quem são os monorepostos?

Monorepos são uma boa opção para grandes equipes com vários projetos. Os benefícios não são necessariamente aparentes com um punhado de pequenos projetos. Os monorepos funcionam melhor em uma escala em que haveria uma ineficiência perceptível com uma abordagem multi-repo.

Monorepos não são iguais aos monólitos. Um monólito geralmente descreve um aplicativo em que os dados e as camadas de apresentação são misturados. Todo o sistema é implantado sempre que uma mudança é feita.

Monorepos geralmente encapsulam vários sistemas. Eles têm vários artefatos de saída, como uma API, um site e um aplicativo móvel. Nem todos os artefatos precisam ser produzidos para cada mudança. Os monorepos destinam-se a facilitar o compartilhamento e a refatoração de código. Eles não se destinam a resultar em um sistema fortemente acoplado que é artificialmente ligado.

O padrão não é para todas as equipes. Em muitos casos, vários repositórios serão mais fáceis de trabalhar. Freqüentemente, eles parecem mais lógicos e podem ser mais fáceis de dominar. Você não precisará resolver conflitos de mesclagem em partes distintas do sistema e é mais fácil lidar com as versões. Os pipelines de CI serão mais rápidos, pois você não testará todos os projetos em cada pipeline.

Repositórios dedicados também apresentam um histórico de commits mais limpo. Histórias de monorepo são poluídas por commits feitos para todos os projetos dentro do repo. Isso torna mais difícil rastrear como os componentes individuais evoluíram.

Vários repositórios são mais fáceis de integrar com software de controle de versão como GitHub e GitLab. Essas ferramentas pressupõem um mapeamento um a um entre repositórios e projetos. Pode ser complicado rastrear problemas e receber solicitações em um monorepo. Você precisará usar tags diligentemente para definir o escopo de cada problema para o projeto apropriado.

Finalmente, observe que a maioria das organizações com monorepos estão usando infraestrutura especializada para apoiá-los. O Git não foi projetado para monorepostos e pode ter problemas se você atingir uma escala suficiente. Ter milhões de objetos em seu histórico de commits pode resultar em lentidão quando o Git precisa andar no gráfico.

Resumo

O padrão monorepo simplifica o compartilhamento de código e melhora a visibilidade de seus ativos. Isso tem o custo de um histórico de commits limpo, maior risco de conflitos de mesclagem e suporte insuficiente de ferramentas populares. Você também pode ter problemas de desempenho à medida que o monorepo cresce.

A transparência de um monorepo não será apropriada em todos os cenários. Se você estiver em um ambiente rigidamente regulamentado, pode ser necessário usar repositórios individuais para que possa aplicar os controles de acesso apropriados. Monorepos também aumentam o risco se o dispositivo de um funcionário for perdido ou roubado. Pessoas com acesso físico seriam capazes de visualizar todo o seu código, em vez de apenas os projetos relevantes para aquele indivíduo.

A decisão de usar um monorepo deve ser baseada em seus próprios projetos, nas dependências entre projetos e nos membros da equipe. Não olhe para as grandes empresas de tecnologia e espere observar o sucesso delas em seus próprios projetos. Há mais na boa cultura de código do que o tipo de repositório que você usa. Monorepos fazem mais sentido quando as pessoas já estão colaborando livremente em projetos cruzados por sua própria vontade.