No primeiro post sobre mono-repo, tentei trazer de forma menos técnica, quais os benefícios e vantagens, assim como qual o fator determinante para o sucesso desse tipo de abordagem.
Nesse post, vamos falar um pouco sobre a organização dos projetos e packages dentro de um mono-repo.
Workspace
Embora uma das principais vantagens de um mono-repo seja facilidade no compartilhamento de código, é preciso determinar os limites desse compartilhamento, ou seja, precisamos definir um espaço onde somente algumas pessoas tem “autorização” para realizar mudanças.
Esse espaço, também conhecido como workspace, é o primeiro nível de separação dentro de um mono-repo, ou seja, uma pasta criada na raiz do repositório.
Existem várias formas de criar essa separação, sendo as três principais por:
- produto: todos os micro-serviços referentes à um produto são armazenados juntos.
- time: todos os produtos que são de responsabilidade do time são armazenados juntos.
- domínio: todos os produtos de um determinado domínio da empresa são armazenados juntos.
Todas as abordagens tem vantagens e desvantagens. No entanto, como elas variam muito de empresa para empresa, não vou fazer esse comparativo aqui.
Shared
Como dito anteriormente, uma grande facilidade que temos dentro de um mono-repo é o compartilhamento de código.
Para que os packages comuns a todos os projetos não se misturem com as especificidades de cada um, é muito importante que esses packages sejam armazenados em um workspace compartilhado.
Esse workspace, quando pensamos em Go, normalmente leva o nome de pkg. Assim, packages para conexão com bancos de dados, filas, logs e etc… ficarão agrupadas nesse workspace, podendo ser utilizado por todos os projetos do mono-repo.
Permissionamento
De nada adianta ter toda essa separação que falamos até aqui, se todo mundo puder alterar/adicionar código em qualquer lugar, sem que os responsáveis sejam informados.
Por isso, é extremamente importante que um arquivo de CODEOWNERS ou semelhante a isso, seja criado e bem gerenciado.
Através desse arquivo, podemos colocar quem são os grupos responsáveis por cada workspace. Assim, caso haja uma contribuição cross, o time responsável poderá avaliar o impacto da mudança antes de aprová-la ou não.
Para o caso do pkg, idealmente, um grupo mais senior deverá ser o responsável pelas alterações dentro desse workspace. Isso não impede que outras pessoas façam mudanças e abram pull requests, apenas que essas mudanças serão revisadas por uma equipe mais senior.
Conclusão
Nesse segundo post da série sobre mono-repo, falamos sobre como criar os workspaces para que os times possam trabalhar mais a vontade em seus produtos.
Note que em nenhum momento eu falei sobre a estrutura de pastas dentro dos workspaces. Isso por que, a forma como os times trabalham dentro dos seus workspaces, não deve gerar nenhum impacto para o mono-repo.
No próximo post vamos falar sobre tooling.
Não deixe de se inscrever na nossa newsletter para receber os posts diretamente na sua caixa de entrada.
Até a próxima!