monorepo - Monorepo único para vários projetos de grande porte e porte da empresa

5

Estou precisando de um conselho antes de ir adiante.

Eu quero construir vários projetos de grande escala, como um produto de mercado e alguns produtos e bibliotecas específicos de domínio. Os produtos podem ou não estar relacionados, mas podem compartilhar bibliotecas. Cada produto pode muito bem ser suas próprias empresas [por exemplo, o mercado]].

Eu sou para usar monorepos. Há tantos benefícios quanto desvantagens. Pontos Pro-monorepo são discutidos em Vantagens do controle de versão monolítico em danluu .com e nos links associados no artigo.

Por que eu acho que preciso de um monorepo - eu li sobre as vantagens do monorepo, mas estou focado principalmente em seguir:

  • Compartilhando código de código fechado. Os produtos e projetos compartilharão bibliotecas internas (de código fechado). O compartilhamento de código se torna mais simples porque as dependências de código fechado estão disponíveis localmente. Os repositórios baseados em projetos requerem ferramentas adequadas para construção. Estou tentando evitar esse requisito, pois não consigo encontrar nenhuma ferramenta para gerenciar dependências de código fechado usando vários repos.

Por que os monorepos serão um problema

  • Incapacidade de escalar.
  • Incapacidade de reverter as alterações sem grandes problemas.
  • Incapacidade de ocultar código sensível. Como os produtos e projetos compartilham um único repo, o código de um produto será exposto.

Perguntas

  • Qual é a melhor prática para gerenciar vários projetos de larga escala de código fechado em um monorepo?
  • Seria sensato (e são) ter esses projetos de grande escala no mesmo repositório?

Obrigado rapazes

    
por eurekasfray 17.09.2017 / 00:22
fonte

2 respostas

2

Para gerenciar a complexidade em grande escala, o princípio vencedor desde Júlio César é " Divide et impera ", em inglês dividir e governar (ou dividir e conquistar). Este princípio se aplica a impérios políticos e a impérios de software.

Engenheiros de Software não pretendem conquistar impérios, então eles chamam isso de forma diferente. As principais variantes desse princípio são separação de interesses , componentização e encapsulamento (no sentido de esconder informações, que está escondendo os componentes internos de um componente). Todos esses princípios são baseados no fato de que é mais fácil construir peças independentes e, quando necessário, montar as caixas pretas para obter maior valor sem se perder em detalhes e interações e dependências inesperadas.

A adoção de vários repositórios independentes permite capacitar as diferentes equipes participantes a usar os procedimentos que melhor atendem às suas necessidades, gerenciar diferentes cronogramas de liberação e - por que não - abrir código aberto, vender ou subcontratar os diferentes componentes para otimizar a eficiência (por exemplo, abrir uma biblioteca mais geral, mas ainda manter controle sobre seus outros produtos mais específicos).

Tudo isso (e além dos muitos outros desafios relacionados ao monolito) certamente explica por que Os monorepos são hoje mais a exceção do que a regra. Eu recomendo vivamente que reconsidere a sua escolha.

    
por 17.09.2017 / 15:22
fonte
0

Focando um pouco no que você listou como problemas.

Inability to scale

Um monorepo não é um repositório único, é uma coleção de repositórios (quantos você quiser, potencialmente mesmo usando sistemas de controle de versão diferentes) gerenciados juntos de uma maneira monolítica para que apareça como um único repositório. A escalabilidade do (s) sistema (s) de controle de versão não é um problema.

Como você ainda está pensando em usar um único repositório, eu acho que você não é um dos poucos casos em que puxar um espaço de trabalho com toda a base de código seria problemático devido ao tamanho. Tais casos exigiriam formas inovadoras de construir os produtos.

Alguns monorepos têm suporte para operação esparsa - um espaço de trabalho conteria apenas um subconjunto dos repositórios da base de código. Veja também Expansão de Monorepos Contratantes .

Inability to rollback changes without major problems.

Isso não é um problema, devido ao gerenciamento monolítico - basta reverter a versão do monorepo, que deve reverter de forma coerente cada um dos repositórios envolvidos para as versões corretas.

Inability to hide sensitive code. Because products and projects share a single repo, code from one product will be exposed.

Novamente, nem um único repo.

E agora as perguntas.

What's the best practice for managing several closed-source large-scale projects in a monorepo?

Donno sobre melhor , pessoas diferentes têm opiniões diferentes :) Falo de uma extensa experiência com um monorepo (personalizado) com mais de mil repositórios, servindo muitas equipes e produtos incorporados (compartilhando grandes quantidades de código):

  • desencorajar desenvolvimento independente nos repositórios individuais do monorepo, tudo deve consistentemente passar pelo monorepo, com um bom sistema de CI / CD operando no nível do monorepo
  • melhor serviu IMHO com Desenvolvimento baseado em tronco

Would it be wise (and sane) to have these large-scale projects in the same repo?

No mesmo repo, provavelmente não. Em um monorepo, IMHO sim - você já conhece as vantagens.

    
por 22.09.2017 / 07:04
fonte