Como usar monorepo para desenvolver grandes projetos | Alura Cursos Online
Como usar monorepo para desenvolver grandes projetos
7 min7 minutos de leitura
7 min7 minutos de leitura
Autor(a)
Camila Pessôa
Oi oi, sou a Camila ! Ingressei na área de tecnologia por meio da robótica educacional e comecei os estudos em programação com desenvolvimento web e foco Back-end com Node.js. Adoro ler, assistir séries/filmes, animes, jogar e passear ao ar livre com minha filhota.
Tenho tenho grande paixão por educação e tecnologia, pois acredito que essa combinação é transformadora! :)
Inscreva-se em nossa Newsletter
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
No entanto, a primeira coisa que nos deparamos é com a enxurrada de material sobre o assunto e isso pode nos deixar meio confusos sobre a principal ideia por trás do uso de Monorepos - ou mesmo sobre o que são monorepos!
Apesar do que se pode imaginar, a prática de desenvolvimento com Monorepos não é algo novo. Recentemente a estratégia voltou como tendência e ganhou notoriedade com cases de sucesso como da Google e Uber.
Monorepo, como o nome sugere, vem de mono (monolithic) repositório (repository), ou seja, é um único repositório para vários projetos ou dependências (é diferente de uma aplicação monolítica).
Em outras palavras, é uma prática de desenvolvimento de software que mantém um projeto maior com todo o código e vários pequenos projetos em seu interior.
Não entendeu? Posso te explicar melhor...
Vamos olhar um pouco mais de perto com uma representação de um Monorepo. Logo abaixo podemos observar um exemplo de várias aplicações em uma única organização, um único repositório, essa estrutura configura o que entendemos como um Monorepo:
As aplicações e bibliotecas estão vinculadas a um único repositório. Essa prática centraliza os processos e garante a visibilidade de todos os projetos por todas as equipes envolvidas. Nesse sentido, é preciso ficar atento às mudanças, pois uma alteração em um projeto pode comprometer o comportamento de outros. Algo que é bem diferente no sistema de Poly-repo ou Multi-repo.
Mas você deve estar se perguntando: Poly-repo? Multirepo? como assim? Como isso funciona? Para facilitar a visualização, vamos observar o que seria um Poly-repo ou Multi-repo:
A figura acima representa o conhecido Multi-repo (multiple repository) ou Poly-repo. Em sua estrutura, observamos que há vários repositórios contendo diferentes aplicações e eles se relacionam com uma Library Repo, uma espécie de base de dados para dependências. Dessa forma temos maior independência entre os projetos e consequentemente, uma descentralização entre times.
Outra forma de entendermos é com o uso de casos. Vamos lá?
Imagine que seu cliente solicita um e-commerce com mobile, front-end e um sistema desktop. O seu tech lead, ou seja, o líder técnico de sua equipe, sugere que cada time trabalhe com um projeto e um repositório distinto para sua aplicação.
A escolha de Multi-repos para esse projeto gera, então, no mínimo 3 pull-requests e reviews diferentes, 3 deploys, maior quantidade de dependências ou até sua duplicação e às vezes o lançamento de uma feature em um projeto antes do outro.
Algo interessante é que a arquitetura Multi-repo proporciona maior autonomia aos times, pois podem realizar modificações em seus repositórios sem necessariamente comprometer os outros projetos. Porém, é comum o multi-gerenciamento gerar algumas dores de cabeça.
Por outro lado, a arquitetura de Monorepo permite maior transparência e centraliza os processos. O que isso quer dizer? Com a prática de versionamento unificado, o gerenciamento de dependências também se torna mais simples.
Além disso, esse compartilhamento de código favorece a prática das chamadas alterações atômicas (atomic commit), que são operações visando a implementação de apenas uma feature ou correção de um único erro. Em teoria, isso facilita a refatoração em larga escala e mantém a consistência do código.
Um exemplo clássico para fazer essa diferenciação é a estruturação de uma aplicação monolítica em Poly-repo ou Multi-repo em Monorepo, olha só:
Primeiro temos uma aplicação monolítica que divide seus quatro projetos em quatro repositórios, os Multi-repo. Já o monorepo utiliza apenas um repositório para englobar os quatro projetos.
Que tal experimentarmos um Monorepo na prática? Confira o tutorial no Github e como é a carinha de um Monorepo com uma estrutura simplificada, olha só: Tutorial Monorepo JavaScript.
Ah, mas se os Monorepos são uma solução tão boa, por que então não é usado por todo mundo?
Diante de todos os benefícios que essa arquitetura proporciona, alguns desafios também surgem. Afinal, quando o assunto é a escolha de uma técnica ou ferramentas, sempre vamos cair no limbo do “depende”.
Nesse sentido, vamos conhecer também alguns desafios na implementação de Monorepos:
Velocidade: os desenvolvedores precisam criar estratégias de automatização que entendam a base de código. Além disso, em um primeiro momento, pode demorar um pouco para a pessoa desenvolvedora entender como sua contribuição pode impactar todos os projetos;
Orquestração de processos: como todos os projetos estão em apenas um repositório, qualquer pequena alteração pode comprometer diferentes aplicações. Dessa forma, realizar automação, gerenciamento e coordenação de processos é uma tarefa complexa;
Complexidade: Monorepos não são tão simples assim, há muito para gerenciar e também um commit pode quebrar mais de um projeto. Mapear o que é funcional em um package, ou em vários packages e aplicações, é uma tarefa complexa e nem sempre está bem documentada. Dessa maneira a automatização de scripts deve ser precisa e muito bem feita para funcionar corretamente;
Segurança: a estrutura permite o acesso de todas as pessoas desenvolvedoras em todos os projetos. Embora esse ponto não devesse ser um problema, visto que toda a equipe deveria zelar pela segurança das informações, já há ferramentas específicas para a manutenção da segurança de informações sensíveis em Monorepos.
Ok, agora a confusão aumentou… então, quando parece uma boa ideia utilizar Monorepos com minha equipe?
Quando usar Monorepo?
Uma das principais características dos Monorepos é a visibilidade e colaboração!
Dessa maneira, quando houver necessidade de maior compartilhamento e reutilização de código, podemos considerar isso um indicativo de que possivelmente sua empresa precisa repensar a prática de versionamento.
Pensando nisso, trouxe aqui uma lista com algumas circunstâncias a serem consideradas na hora de escolher um único repositório para gerenciar seus projetos:
Deseja maior colaboração entre os times;
Necessidade de ter uma única fonte de verdade;
Deseja compartilhar e reutilizar o código facilmente;
Maior visibilidade no momento de gerenciar dependências (quando você realizar uma mudança, todo o resto do código será impactado?);
Deseja realizar uma operação para várias mudanças em múltiplos projetos: atomic changes (alterações atômicas);
Deseja realizar mudanças e refatoração em larga escala.
Nunca é demais lembrar que não existe fórmula mágica! É necessário avaliar cada caso e verificar se os custos de implementação de Monorepos são viáveis e fazem sentido no contexto dos seus projetos.
Por fim, vou deixar nossa colinha com algumas das principais vantagens no uso de Monorepos:
Fonte: elaboração própria
Conclusão
É interessante observar a “volta” de estratégias que pareciam obsoletas e que eram utilizadas em outro contexto, não é?
O caso desse “retorno” do uso de Monorepos por grandes empresas agora é bastante representativo nesse sentido, pois a prática era comumente pensada para projetos pequenos e que possuíam uma equipe pequena também.
No entanto, sua aplicação em projetos gigantes que atuam com múltiplos times e milhares de dados se tornou uma solução viável ao problema de gerenciamento.
Sabemos que no início sempre há aquele trabalho de implementação. É um processo parecido com uma obra em prédios ou em nossa casa, fica aquela poeira e várias paredes quebradas, mas no fim tudo fica em ordem e bem melhor do que era anteriormente.
A situação de fato é compreender a necessidade da estratégia e se realmente irá trazer ganhos ao processo de desenvolvimento do projeto.
