Construindo um projeto Android com multi repositórios

Em projetos Android é muito comum você escutar sobre modularização, uma técnica que trás alguns benefícios como melhoria no tempo de build, e que é essencial para utilizar com outras tecnologias do google como Dynamic Features. Conforme aumentam as demandas da aplicação, acabamos modularizando nosso código em novas funcionalidades ou componentes lógicos. Chega, porém, um momento em que existem tantos módulos o que onera demais os tempos de build durante nosso dia-a-dia.

Isso não é diferente do que acontece na XP Investimentos, onde trabalhavamos em um projeto com uma escalabilidade muito alta, indo para um número superior a 80 módulos, além disso, a própria XP Investimentos tem outros produtos dentro da própria empresa. Com isso, o nosso direcionamento inicial estava seguindo o mesmo caminho de tantas outras empresas, já que esse é um problema bem comum em grandes organizações, que normalmente utilizam um único repositório sendo conhecido como o famoso “monoRepo” onde ficariam todos os produtos da empresa no mesmo repositório. No nosso caso alguns pontos de negócio ajudaram a tomar um direcionamento um pouco diferente do que tem seguido o mercado.

Devido a necessidade de reaproveitar o máximo de código possível, sejam telas ou lógicas, e mais do que isso diminuir o atrito sem a necessidade de recriar a roda, optamos por seguir pra uma proposta de multi repositórios, isto é, realmente transformar nossos módulos de funcionalidades em SDKs independentes funcionando como um desejado plug-and-play que pode ser reutilizado em outras aplicações. Como consequência, isso ajudaria muito o nosso tempo de build, já que cada vez mais externamos o código dentro do repositório da aplicação para virarem SDKs futuramente.

Com isso seguimos uma abordagem onde será explicado alguns resultados até o momento e sobre os problemas que tivemos sobre isso.

Agora que temos um pouco de contexto, vamos lá

A ideia desse post, é ser um sumário de vários pontos que serão abordados com mais detalhes de maneira individual em outros artigos.

Inicialmente foi preciso pensar como funcionaria essa dinâmica de vários SDKs, pois todos os SDKs seriam consumidos pelo App atual e/ou por outros Apps futuramente. Para isso utilizamos convenções de nomenclatura em nossos repositórios facilitando o entendimento:

• App Principal / App Root-> É o repositório original do App (.apk) que será publicado na loja e que irá consumir todos os SDKs gerados;
• SDK de Feature -> São SDKs que fornecem diretamente conteúdo para o App Principal, como fluxos completos possuindo as telas e as interações do App Principal.
• SDK de API -> São repositórios que fornecem apenas serviços de chamadas, sem telas. Essas classes já tem o mapeamento correto para o objeto para a aplicação e já passou por regras de negócio. Onde em tese qualquer outra SDK de Feature poderia consumir;

Para que tudo isso fosse possível, foi necessário inicialmente criar um pipeline bem estruturado, para estar preparado a externalizações dos módulos. Com esse ponto de partida, irei explicar o funcionamento do fluxo de geração desde o artefato de SDK de Feature até a geração de um apk no App Principal para ser validado. E para que tudo isso funcione de maneira fluída, como uma roda girando, para a equipe inteira de Android da empresa foi preciso automatizar esse processo.

Assim será dividido em duas partes o fluxo de SDK de Feature:

Fluxo do Pipeline Android em ambiente de desenvolvimento na XP Investimento

E a parte do fluxo do App Principal de como será obtido todos esses artefatos e gerado uma versão release, será abordado posteriormente, mas fica o resumo ilustrado abaixo:

Beleza, me mostra que ferramentas foram utilizadas!

E para tudo isso ser feito, foi utilizado algumas ferramentas:

- Azure DevOps Multistage Pipelines em YAML

Documentação oficial das pipelines do Azure DevOps: https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started/what-is-azure-pipelines?view=azure-devops

Segundo o yaml.org:

What It Is: YAML is a human friendly data serialization standard for all programming languages.

É comum o uso de YAML em arquivos de configuração, no nosso caso ele será o que utilizaremos para a pipeline.

- Fastlane

É uma ferramenta open source escrita em Ruby para continuous delivery de aplicações tendo um grande poder no nosso fluxo de Android.

Sendo fundamental em todos os processos, ele que é responsável por manipular/incremento as versões durante o pipeline além da publicação pro App Distribution do Firebase, segundo o https://fastlane.tools:

“fastlane is the easiest way to automate beta deployments and releases for your iOS and Android apps. It handles all tedious tasks, like generating screenshots, dealing with code signing, and releasing your application”

- Gradle

Esse último dispensa apresentações, o nosso velho conhecido gradle.

e dai? depois tudo isso, vale a pena ?

Essa é uma visão macro de como o fluxo está sendo utilizado tendo alguns pontos sobre isso:

Vantagem

Obtivemos alguns benefícios já que cada vez mais os módulos do App Principal estão sendo externalizados, melhorando consideravelmente nosso tempo de build, e claro, a nossa organização de código onde cada time é responsável pelo seu próprio repositório e processos, não criando impedimentos cruciais para outras equipes no processo de geração de artefatos. Ainda estamos melhorando esse processo todos os dias criando SDKs auxiliarias e de componentes.

Desvantagem

Um grande problema que temos hoje, é que ainda há uma certa demora para gerar uma versão desde a concepção de uma correção ou funcionalidade até disponibilizar para o cliente final. Isso é particularmente preocupante em casos de urgência, onde não temos escolha a não ser esperar todo o fluxo executar, ainda mais considerando que hoje temos vários SDKs sendo utilizados simultaneamente. Além disso, nós passamos por alguns problemas graves em que foi necessário o time inteiro participar das soluções:

• Migração dos módulos;
• Gerar artefatos utilizando modularização;
• Versionamento de bibliotecas.

O dois últimos itens tem um artigo explicando de como foi feito cada parte.

Nós sabemos que temos muito o que podemos aperfeiçoar em nosso processo, mas hoje este já é um processo bem eficaz. Gostaria de deixar alguns agradecimentos para o time inteiro de Android da XP Investimento que ajudou nas migrações e as pessoas que me ajudaram a contribuir de alguma forma nesse nosso projeto: Estevão Henrique Coelho, Daniel Azevedo Marques, Gustavo Santorio, Tiago Missiato Rigoleto sem todos da equipe não seria possível fazer isso.

E isso é tudo galera. Agradeço qualquer feedback, você pode colocar nos comentários abaixo ou entrar em contato comigo no LinkedIn.