O debate entre monorepo e multirepo costuma ser animado entre as equipes.
Para complicar a tarefa, surgiram variações desses modelos iniciais, às vezes a querer agradar a todos.
A realidade é que um repositório é apenas o armazenamento do código-fonte, encontrando-se estruturante na sua integração e impactos nos outros processos.
Este artigo pretende dar um passo atrás no tema dos repositórios : suas características, definições e várias opções.
Junta-se a QE Unit para aceder a mais conteúdos exclusivos da comunidade.
O que é um repositório?
Seu repositório é o armazenamento de seu código-fonte.
Um código que se tornou para um bom número de empresas um dos seus principais ativos, sem necessariamente dar conta disso.
A Google, por exemplo, acumulou até 2015 o impressionante volume de 2 bilhões de linhas de código que representam 84 Tb de armazenamento.
É justamente por meio desse crescimento, tendência à entropia e extensão do código-fonte que precisamos organizar seu armazenamento.
Assim como as fotos ou livros que acumulamos, é necessário estruturar seu armazenamento em álbuns e livrarias para navegar.
Enfrentamos o mesmo desafio na indústria de software, adicionando componentes tecnológicos.
Um repositório é apenas o armazenamento de código?
Como tal, sim.
Para saber o que não é, pode consultar este artigo sobre os x mitos do descanso.
Por que é uma escolha tão importante?
O armazenamento do código e sua organização permanecem complexos por sua integração com o resto do ecossistema.
A organização do armazenamento do código entre arquivos, projetos, bibliotecas irá materializar as interações necessárias para a evolução do código fonte.
Sua estrutura deve ser acionável pelas diferentes equipes.
Essa estruturação impactará os mecanismos de comunicação, processo de desenvolvimento e assim por diante.
O acesso ao código é o que acaba sendo usado pelos desenvolvedores no seu ambiente de desenvolvimento, descarregando localmente ou configurado em pipelines de CI/CD.
Deve-se ter em mente que a escolha da organização do repositório é estruturante para o cumprimento dos objetivos perseguidos globalmente.
Quais opções de repository são possíveis?
Vamos dar um passo atrás para obter uma melhor perspectiva global.
No cerne do assunto dos repositórios, várias opções surgem em diferentes níveis.
Nós temos 2 opções estruturantes para a organização do código fonte:
- Centralizado, também conhecido sob o termo “monorepo”
- Descentralizada, correspondente ao “multirepo”
Estas alternativas são aplicáveis em vários níveis em uma arquitetura de software:
- Globalmente para todo o código fonte de uma organização até o armazenamento do projeto ou de uma função isolada
- Transversalmente pelo armazenamento de funções transversais e compartilhadas entre diferentes projetos
- Tanto para código de aplicativo de negócios, teste, infraestrutura (desde que gerenciado em As Code) ou outros arquivos
Os 4 seguintes modelos existem na indústria:
- “Monorepo” (ou “one-repo”, “uni-repo”)
- “Multirepo” (ou “many-repo”)
- “Hybrid-repo”
- “Split-repo”
Parecem ser demasiadas variações?
Ainda bem que evitamos as várias variações de “repo”, “-Repo” e “Repositório” por uma questão de clareza.
O que é um Monorepo?
Vamos começar com o famoso modelo totalmente centralizado, o monorepo.
A monorepo (mono repository) is a single repository that stores all of your code and assets for every project.
Esta foi historicamente a nossa única opção em um mundo de mainframes e outros sistemas que se tornaram hoje legacy.
Arquiteturas descentralizadas, como SOA ou microsserviços, fizeram com que ele perdesse o interesse, provavelmente de forma incorreta.
Lembre-se de que o monorepo é a organização e armazenamento do código, sem ser diretamente a arquitetura possível da aplicação.
Um monorepo pode, portanto, ser composto por vários projetos, aplicações e tecnologias diferentes mais ou menos acoplados por serviços ou bibliotecas compartilhados.
Armazenar todo o seu código-fonte não significa que tenhamos que compilar todo o projeto a cada alteração.
Um forte acoplamento do ciclo de implantação e do repositório se materializa no caso de um aplicativo monolítico armazenado em monorepo.
Além disso, tentar armazenar um aplicativo monolith em multirepo não parece o mais adequado à primeira vista.
Portanto, vamos prosseguir para o seu oposto, o multirepo.
O que é um Multirepo?
Comecemos também com uma linha de definição desse modelo totalmente descentralizado.
Multirepos uses multiple repositories for the source code management version control system.
Uma organização multirepo envolve vários elementos:
- O uso de vários repositórios, geralmente um por aplicativo
- A ausência de dependência de código diretamente entre projetos (teoricamente?)
Uma combinação de tecnologias de sistema de controle de versão é, portanto, possível, por exemplo, entre Git e SVN, embora isso tenha outros impactos na cadeia de integração.
É um modelo que vem sendo amplamente adotado desde a distribuição dos aplicativos, sem necessariamente ser uma escolha equilibrada.
A organização interna de cada repo, projeto e seus diretórios ainda precisa ser estruturada.
Lembre-se de que um sistema descentralizado tende a se otimizar localmente, às vezes em detrimento do sistema geral.
O multirepo não deve ser confundido com o outro modelo denominado de “hybrid-repo” ou seu mutante, o “split-repo” descrito abaixo.
O que é um “Hybrid-repo”?
Um “repo híbrido” é baseado no uso misto de modelos mono e multirepo.
Hybrid repos use a combination of repositories, some being a monorepo and other being multirepos. At the end, they still store the source code of various projects.
Um “repo híbrido” pode ser limitado ao armazenamento de um aplicativo monolith em monorepo, enquanto os serviços distribuídos serão em multi-repo.
Além disso, um repositório híbrido pode oferecer suporte ao compartilhamento de funções e bibliotecas entre as equipes.
Então voltamos a um monorepo?
Não neste modelo, as bibliotecas compartilhadas devem permanecer rapidamente compiláveis e o repository de um tamanho moderado, por exemplo, o tamanho de uma equipe.
Parece uma escolha mista?
É verdade que nos perguntamos por que escolher o multi-repo para finalmente atingir o objetivo do monorepo: compartilhamento direto de código.
O modelo split-repo é uma alternativa para essa necessidade.
O que é um “Split-repo”?
Freqüentemente, encontraremos o acrônimo “read-only” associado ao split-repo.
A split-repo is a monorepo, used for code storage, that is split into read-only repos for building and releasing project artifacts independently.
Antoine Craske
Entendemos que o split-repo é um modelo que quer combinar as vantagens dos dois modelos principais:
- O monorepo para o armazenamento centralizado de código permitindo o compartilhamento de bibliotecas e integração o mais rápido possível
- O multi-repo em a fim de realizar implantações mais granulares, independentes e mais rápidas.
Quanto a um SI, encontramos no multi-repo “ready-only” o conceito de dono dos dados e de várias réplicas para garantir sua consistência.
É um modelo frequentemente escolhido por organizações que preferem um modelo monorepo, mas que exige muito isolar as implantações por tecnologia.
O que lembrar desses diferentes modelos de repo?
O objetivo deste artigo foi fornecer a perspectiva geral e a descrição de cada um dos modelos.
Os principais pontos a lembrar-se:
- Seu repositório é o armazenamento de seu código-fonte
- Seu repositório não é sua cadeia de release, modelo de branching, gerenciamento de dependência, revisão ou processo de comunicação
- Seu escolha do modelo de repositório é estruturante pela sua integrado ao processo de desenvolvimento
- Existem duas alternativas principais: centralizado e descentralizado
- Quatro modelos principais existem: mono-repo, multi-repo, hybrid-repo, split-repo
Atores como a Google são eficientes com monorepo enquanto a Netflix é eficiente em um modelo multirepo.
Portanto, não existe necessariamente uma fórmula mágica, por exemplo, para escolher um modelo de acordo com o tamanho das empresas.
Como escolher entre as diferentes opções de repos?
A escolha do modelo de repositório deve, portanto, ser feita de acordo com o contexto atual e futuro de cada organização, seus objetivos, enquanto gerir os seus trade-offs.
Este é um bom assunto para reflexão, especialmente para os testes, veja Como superar o dilema do Repo de teste. Agora.
Referências
https://medium.com/@mattklein123/monorepos-please-dont-e9a279be011b
https://hackernoon.com/ mono- repo-vs-multi-repo-vs-hybrid-whats-the-right-approach-dv1a3ugn