Recentemente, li uma matéria fascinante sobre a transição da Block, Inc. de uma arquitetura de polyrepo para um monorepo, e não pude deixar de refletir sobre como essas mudanças podem impactar o desenvolvimento de software. A migração, que envolveu a consolidação de cerca de 450 repositórios baseados em JVM, foi impulsionada por desafios crescentes de coordenação e gestão de dependências. O que me chamou a atenção foi a forma como essa mudança não só simplificou o desenvolvimento entre serviços, mas também melhorou a visibilidade das dependências e reduziu a fricção operacional.

Desafios do Polyrepo

No modelo anterior de polyrepo, os serviços e bibliotecas compartilhadas eram mantidos em repositórios separados. Isso permitiu que as equipes operassem de forma independente, mas, com o tempo, a complexidade de coordenação aumentou. O resutlado? Versões de dependências que se desviavam, esforços de atualização duplicados e um risco maior de incompatibilidades em tempo de execução. É quase como se estivéssemos sempre à beira de um colapso, apenas esperando que um pequeno ajuste quebrasse tudo.

A Revolução do Monorepo

Com a mudança para o monorepo, a Block conseguiu realizar cerca de 8.800 builds por semana, com tempos de CI em torno de 10 minutos. Isso é incrivelmente rápido, considerando a quantidade de código que está sendo processado. Um dos pontos mais interessantes que o Gabor Pap, gerente de engenharia sênior, mencionou foi que o que começou como uma migração complicada se transformou numa experiência de desenvolvedor muito mais agradável. Isso me faz pensar em como a arquitetura de software pode, de fato, ser um catalisador para uma experiência mais fluida.

gerenciamnto de Dependências

Um dos maiores trunfos do monorepo é a capacidade de realizar atualizações atômicas em serviços com um único commit. Isso significa que as mudanças podem ser implementadas sem a necessidade de coordenação entre diferentes equipes ou repositórios. O uso de gráficos de dependência para escopo de builds e testes é uma prática que pode ser muito bem aproveitada. Por exemplo, ao categorizar mudanças em afetadas diretamente, indiretamente e globais, as equipes conseguem otimizar seus processos de CI, evitando builds desnecessários e focando no que realmente importa.

Dicas Avançadas para Implementação de Monorepos

Se você está considerando migrar para um monorepo ou mesmo melhorar a gestão de dependências em seu ambiente, aqui vão algumas dicas:

Conclusão

Em suma, a migração para um monorepo, como demonstrado pela Block, não só aborda os problemas de gestão de dependências, mas também melhora significativamente a experiência do desenvolvedor. É claro que essa abordagem não é uma solução mágica para todos os problemas — um suporte adequado e investimentos em equipes de plataforma são cruciais. Se sua equipe não consegue se comprometer com a manutenção de um monorepo, talvez seja melhor continuar no modelo de polyrepo, onde a autonomia das equipes pode ser mais benéfica. Afinal, a arquitetura de software deve sempre servir aos nossos propósitos, e não o contrário.