Padronização de versões de bibliotecas em projetos Android multi repositórios
Esse artigo é um complemento do Construindo um projeto Android com multi repositórios, onde explico os pontos que levaram a XP Investimentos a repensar seus fluxos e processos fazendo com que o time de Android adotasse uma abordagem diferente do “monoRepo”, e como iniciar a revisão dos nossos processos pelo pipeline CI / CD nos ajudou.
É muito comum em projetos Android ter um arquivo de versionamento onde possui todas as versões de todas as bibliotecas para controlá-las e com isso poderá ser utilizado para vários módulos garantido a mesma versão em todos.
Porém em projetos muitos grandes é natural que versões de bibliotecas podem gerar alguns conflitos na hora da integração como descrito em um dos meus artigos "Construindo um projeto Android com multi repositórios" ou caso o time inteiro queira manter um padrão de versões de bibliotecas mesmo em projetos distintos na mesma empresa. Encontramos uma abordagem que facilita esse controle, e evita que esse risco aconteça.
Tem diversas formas que pode ser feito isso, a que fizemos é criar um repositório a parte com apenas um arquivo de versionamento conforme imagem:
Com o seguinte trecho de código que terá as variáveis declaradas com suas bibliotecas, como por exemplo:
Após isso dentro do projeto da aplicação adicionar no build.gradle do root, o bloco de afterEvaluate, ele irá ser executado quando sincronizar o projeto antes da execução do build.gradle do modulo app, fazendo com que através do curl faça o download do arquivo e adicione na raiz do projeto. Em seguida será adicionado no gradle para todos os módulos através do "apply from:".
Groovy:
No build.gradle dos seus módulos precisam apenas declarar as variáveis que estarão sendo utilizadas com o mesmo nome que estão no arquivo version.gradle.
Groovy:
Pronto! Toda vez que for sincronizar o projeto, será feito o download do arquivo de versões com todas as bibliotecas atualizadas e padronizadas com seu time!
Uma observação, nem todos os lugares poderão ser repositório públicos, no entanto essa solução também funciona se você passar a autenticação pela URL. Além disso, você também pode passar na URL parâmetros de branches como develop, master e etc…
Agradecer que essa solução foi pensada, desenvolvida em conjunto com Gustavo Santorio e Estevão Henrique Coelho
E isso é tudo galera. Agradeço qualquer feedback, você pode colocar nos comentários abaixo ou entrar em contato comigo no LinkedIn.
