Uma conversa originalmente sobre repos tende rapidamente a mudar para a sua branching strategy ou gestão de dependências.
Qual é o real impacto de um mono ou multirepo na arquitetura, na organização e nos processos de desenvolvimento?
É isso que vamos explorar através dos mitos de nossos famosos modelos de repository.
Pode ler esses artigos de introdução aos repos A épica História do Mono vs. Multi-Repo não é nova e Os principais modelos de Monorepo e Multirepo que precisa de conhecer.
Junta-se a QE Unit para aceder a mais conteúdos exclusivos da comunidade.
O seu Repo não é a arquitetura de seu projeto
Seu repositório é o armazenamento do código-fonte, em particular dos projetos de vários aplicativos.
A organização interna do seu projeto reflete amplamente o estilo de arquitetura retido, seja em SOA ou microsserviços.
Pode armazenar seus projetos, seus diretórios e subdiretórios como desejar, seja em mono ou multi-repos.
A arquitetura de seu aplicativo é, portanto, um tema muito mais amplo, cujo repositório é um dos elementos de suporte.
Monorepo! = monolith; Multirepo! = microsserviços; continued;
Antoine Craske
Diferentes níveis devem ser considerados na arquitetura de seu aplicativo:
- A arquitetura geral de seu Sistema de Informação (SI)
- A arquitetura localizada por contexto (por exemplo, Front-office, Back-office, Data)
- A arquitetura local para uma aplicação
O estilo de arquitetura escolhido pode ser alinhado entre diferentes contextos, mesmo que sua tendência seja para a diversificação durante o seu crescimento.
Determinadas arquiteturas são mais adequadas a um modelo de repo específico, em um contexto organizacional igualmente alinhado.
Por exemplo, uma arquitetura de microsserviços distribuída suportada por equipes descentralizadas será mais adequada a um modelo multi-repo.
É o caso, por exemplo, da Spotify e da Netflix.
Deve ser lembrar que:
- O estilo de arquitetura e o modelo de repositório são escolhas diferentes
- Um estilo de arquitectura deve ser analisado em diferentes níveis, assim como o seu modelo de repositório
- Há uma necessidade de coordenar a sua decisão de repositório e de arquitetura por suas aderências
O seu Repo não é sua branching strategy
Vamos continuar nossa análise no processo de desenvolvimento.
Qual é o impacto do trunk-based development, do gitflow e outros modelos no assunto de repo?
Vejamos alguns exemplos.
Queremos implementar o trunk-based development a escala à la Google e estamos fazendo a pergunta de mono ou multirepo.
Ambos os modelos são possíveis.
Sua implementação terá diferentes implicações dependendo dos modelos:
- O modelo mono-repo requer ferramentas e processos de CI/CD mais específicos
- O multirepo será reduzido a uma implementação mais localizada e descentralizada de pipelines de builds e releases por projetos
A mesma lógica se aplica a outros modelos de branching e de repos.
O que se lembrar deste tópico:
- Sua estratégia de branching não é o seu modelo de repo
- A implementação de sua estratégia de branching tem implicações diferentes consoante seu modelo de repositório
O seu Repo não é o gerenciamento de dependências
Ah às “dependências”, o pesadelo do software, que gostaríamos de livrar-se delas.
Alguns exemplos de dependências:
- A versão do Java usada pelos projetos
- Sua biblioteca interna de logging
- Uma biblioteca core com o modelo de objeto de negócios
A realidade é que essa complexidade existe e tenderá a entropia, daí a necessidade de contê-la.
A gestão das dependências necessárias pode ser abordada, como as dos repos, com duas abordagens:
- Centralizada: as famosas bibliotecas e libs comuns
- Descentralizada: a famosa pecado da duplicação de código
Ambos os modelos de gestão de dependências podem ser implementados independentemente do seu modelo de repositório.
Pode duplicar o código, seja funcional ou técnico, em diferentes diretórios do seu monorepo ou multirepo.
Você também pode escolher usar bibliotecas referenciadas entre projetos nos dois modelos.
Cada um dos modelos tem implicações diferentes em seu repositório.
Um monorepo tornará mais fácil ter uma visão global, por exemplo na duplicação, ou atualizar dependências mais diretamente.
Por outro lado, visualizar código duplicado entre vários repositórios será mais difícil de visualizar.
Os pontos importante a se lembrar:
- O modelo de repositório não é seu gerenciamento de dependência
- Você pode combinar vários modos de gerenciamento de dependências
- Seus mecanismos de gerenciamento de dependências devem ser adaptados de acordo com seu modelo de repo
O seu Repo não é seu gerenciamento de versão
A continuação lógica das dependências segue para o gerenciamento de versão.
Vamos passar o assunto da escolha de Git, SVN ou outras tecnologias de controle de versão, que tendem a se resumir em usar Git (quando entendido e usado corretamente).
Vamos nos concentrar aqui na estratégia e nas práticas de controle de versão:
- Quais regras de nomenclatura para nossos artefatos ? (por exemplo, major.minor.fix)
- Qual política para atualização de bibliotecas internas?
- Quais são as práticas para atualizar APIs públicas?
Tantas perguntas que deve responder e configurar independentemente de sua escolha de repositório.
A escolha terá diferentes implicações, desde a implementação, visibilidade e manutenção que serão diferentes dependendo do modelo de repo.
Vou evitar-vos os dois pontos de conclusões que começam a se repetir.
O seu Repo não é a sua release pipeline
Você quase poderia pensar em trabalhar na indústria do petróleo falando tanto sobre pipelines.
Seu processo consiste em três etapas principais:
- Build : Construir artefatos
- Deploy : Instalar nos diferentes ambientes
- Release : Ativar os serviços, mais ou menos gradualmente
A ligação com seu repo é bastante estruturante, pelo menos a etapa Build conterá o caminho para seu repositório configurado.
Se o seu projeto tiver uma dependência core atualizada, ela deverá ser atualizada.
Se um projeto tiver diretórios desorganizados, misturando tecnologias por diretórios, provavelmente precisará classificar e organizar isso antes de configurar seus pipelines.
O vínculo mais forte entre suas pipelines e seu modelo de repositório está, portanto, localizado ao nível do projeto e do aplicativo.
O modelo split-repo, por outro lado, é o mais estruturante em relação aos seus pipelines, tendo que adicionar uma etapa adicional de separação de diretório antes de construir seu aplicativo.
Mesma conclusão: assuntos diferentes com aderências mais ou menos fortes dependendo do modelo.
O seu Repo não é sua cultura de engenharia
Um monorepo não nos tornará em uma futura Google.
Infelizmente, um multirepo também não nos transformará no próximo Spotify ou Netflix.
Por outro lado, esses grandes actores ponderaram fortemente suas decisões de repository de acordo com a cultura de engenharia que desejavam desenvolver.
Lembre-se das diferentes noções de correlação e de causalidade.
Infelizmente não se tornará numa Google apenas adotando um monorepo.
Antoine Craske
A Google investiu significativamente no seu monorepo, que demonstrou sua capacidade de expandir e até mesmo acelerar os commits ao longo dos anos.
Uma cultura de partilha global, de construção de um produto comum e práticas como o trunk-based development estão no centro de seus processos.
A Spotify também investiu na sua cultura de engenharia em um modelo mais descentralizado apoiado por multirepos.
Em ambos os casos, os modelos têm suportado o crescimento e a expansão da organização.
O ponto chave é alinhar o modelo de repositório com a arquitetura da empresa, da organização e das aplicações.
O seu Repo é estruturante, mas não é tudo
O compartilhamento desses diferentes mitos reflete a importância da escolha do repositório.
O pattern recorrente é que os outros componentes de sua arquitetura de desenvolvimento estão intimamente ligados ao seu modelo de repo, sem condicionar uma escolha em particular.
Compreender os diferentes modelos continua a ser fundamental para identificar e alinhar os impactos nos vários processos.
É o assunto dum futuro artigo de guia de mono e multirepos
Referências
https://hackernoon.com/mono-repo-vs-multi-repo-vs-hybrid-whats-the-right-approach-dv1a3ugn