Embora tenham naturezas diferentes, como vocês preferem integrar (ou não integrar) vários projetos relacionados?
Por exemplo, se houver front-end, back-end (api), serverless, batch, pipeline etc. para o mesmo serviço,
-
Mono-repo
Se o serviço é o mesmo, então o repositório é um só! Cada projeto fica na estrutura de pacotes/pastas
-> Mas como fica a gestão dos commits..? CI/CD ou hooks como pre-commit vão acabar ficando complexos.. -
Git Submodules
Se a natureza é diferente, então pelo menos o histórico do git deveria ser gerenciado separadamente! Ainda assim, tentando agrupar tudo o máximo possível..
-> Tem a curva de aprendizado de coisas como sync de submodule.. merge também fica mais complicado.. será que outros desenvolvedores vão acompanhar? -
Repositórios separados
Simples! Se são projetos diferentes, então repositórios diferentes!
-> Para ver o serviço A, qual repositório eu preciso olhar? Ah, esse aqui, aquele ali,.. e o que mais tinha mesmo...
Acho que não existe resposta certa, mas queria saber qual vocês preferem e por quê!
16 comentários
Eu prefiro repositórios separados...
Quando surge a pergunta "se eu quiser ver o histórico da API relacionada a esta funcionalidade, o que exatamente devo olhar?", acho mais prático manter um repositório correspondente a cada funcionalidade.
Eu uso monorepo na maioria dos casos, mas há 2 situações em que uso submodules.
Quando contratamos um publicador externo.
Uso submodule quando não quero expor ao publicador externo coisas além das informações necessárias para a publicação.
Quando é preciso customizar uma solução externa.
Especialmente quando se trata de uma solução que oferece funcionalidade de plugin, uso submodule.
Registro essa solução externa como submodule e trabalho colocando meus plugins dentro do caminho de plugins por meio de symlink etc. Meus plugins eu versiono separadamente do meu lado, e a solução externa pode manter o controle de versão deles como está, o que tem essa vantagem.
Pelo visto, todo mundo teve experiências ruins com submodule... Seria ótimo se existisse alguma ferramenta que pudesse melhorar isso.
Se você tem confiança de que vai fazer apenas merge commits, monorepo,
se vai fazer rebase com frequência, multirepo,
submódulo? É só usar os links de diretório fornecidos pelo próprio SO…
Antes eu simplesmente usava repositórios independentes para cada coisa, mas recentemente mudei completamente para uma abordagem usando submódulos.
Antes eu não tinha um bom entendimento de git e não conseguia aproveitar os submódulos direito, mas agora acho que usar submódulos é a melhor opção.
No entanto, ao usar submódulos, é preciso fazer commit no submódulo correspondente e depois fazer commit de novo no repositório pai; como resultado, esses dois momentos acabam ficando defasados, o que parece trazer o problema de reduzir a consistência do repositório.
https://monorepo.tools/
Se você ainda não viu esse site, acho que vale a pena dar uma olhada.
Pela minha experiência pessoal, não recomendo submódulos.
Se você quer compartilhar código de outro repositório com submódulos, acho que é melhor simplesmente publicar como pacote.
No caso da nossa empresa, como há poucos membros por projeto e as linguagens e stacks de frontend e backend são separadas, quase não houve contribuição cruzada entre funções. Como em todos os sistemas de TI, no fim parece que isso acaba seguindo a estrutura da organização.
Ah.. então é uma abordagem para ajustar a visibilidade do código alheio dependendo se a interface é alinhada pelas pessoas ou pela ferramenta, né.
Como não tenho experiência com mono-repo, fiquei com uma dúvida. Ao usar mono-repo, os módulos comuns a vários projetos ou serviços, como por exemplo um design system, também entram nesse mesmo mono-repo? Ou, nesse caso, não tem jeito e eles acabam ficando em um repositório separado para serem referenciados?
Acho que, para acessar módulos comuns, usávamos algo como o Yarn Workspace para acessá-los em forma de symlink!
Na empresa e nos meus projetos pessoais, eu gerencio tudo em um único git, sem separar frontend, backend, batch etc.
Em alguns casos, é mais prático modificar os dois juntos do que se preocupar em manter compatibilidade retroativa. Como as equipes em ambos os casos são pequenas, também penso que não há muito ganho em separar sem necessidade... O trabalho extra de configurar o GitHub Actions para rodar só nas partes alteradas foi algo totalmente aceitável. Acima de tudo, mais do que separar backend e frontend, acho bom que um possa contribuir com o outro. (Por exemplo, enquanto trabalho em prompts, se surge algo necessário no backend eu mesmo adiciono, ou corrijo erros diretamente...)
Hmm, pelo visto, quando a escala é menor ou as funções não são tão rigidamente separadas, vocês parecem preferir monorepo! Vocês também não se importam muito com o fato de o histórico do Git ficar meio misturado? (Já que, no fim, é tudo código que todo mundo vê mesmo?)
O interessante é que isso também acontece no meu projeto paralelo. Trabalhei com cerca de 12 pessoas até agora. Cada pessoa trabalha de ponta a ponta, do frontend ao backend, em um único fluxo. Acho que é algo parecido com vertical slice.
Eu não considero isso como algo misturado. Muitas vezes também modificamos tanto o front-end quanto o back-end em um único PR. Como seguimos a premissa de que todos nós 4 somos full stack, sem separar back-end e front-end, revisamos o trabalho uns dos outros e também precisamos conhecer as mudanças.
Se o módulo não for muito grande, monorepo
se o módulo for grande, submodule
Ou então, se você quiser que, ao distribuir como open source, contribuam apenas com o submodule e que o repositório principal seja gerenciado internamente,
parece fazer sentido separar como submodule.
Mas, quando entra submodule, na hora de open source parece que fica um pouco mais complexo para outros usuários escreverem documentação relacionada a testes ou build para contribuir.
Então, pessoalmente, a menos que o modo de contribuição para os dois seja diferente, eu tenderia a usar monorepo,
ou então usar GitHubs diferentes e gerenciar distribuindo cada um como pacote ou como imagem Docker.
Eu não tinha pensado na questão de open source, obrigado pela opinião!