Evolução: Monorepo iOS da XPInc.

Nos últimos anos a XP passou por um período de hipercrescimento chegando a mais de 6.5k de funcionários. Para acompanhar, o time mobile também não foi diferente. Em 2018 quando entrei na XP, fui um dos primeiros engenheiros e no final daquele ano tínhamos apenas 4 engenheiros iOS e hoje somos mais de 60. Como efeito desse crescimento nossas ferramentas passaram por grandes mudanças para atender à demanda dessa equipe.

Nesse artigo vou me concentrar em por que tivemos que mudar para um único repositório e por tudo que passamos para chegar até ele.

O começo de tudo

Vamos começar analisando como era o mundo mobile na XP em 2018. No iOS contamos com uma ferramenta de código aberto, chamada de Cocoapods, para construir nosso aplicativo principal. O Cocoapods é um gerenciador de dependências e ferramenta de integração tudo em um, ele permite que os desenvolvedores integrem rapidamente outras bibliotecas em seus aplicativos sem a necessidade de configurar coisas complexas no Xcode. Como ele é o gerenciador de pacotes mais popular nós escolhemos ele para o nosso projeto e detalhe que usamos ele até hoje 😉.

Como tínhamos um time pequeno (2 devs), e nosso projeto até então possuía uma baixa complexidade, a estrutura montada nos servia bem e algumas bibliotecas externas ajudavam a alavancar nosso desenvolvimento em uma estrutura monolítica, que nos permitiu focar na construção da parte de investimentos.

Migrando para multi repos

Nossa expansão em 2020 para diversos times e um número grande de contratações nos fez parar durante 2 semanas para analisar o mercado, definir o futuro do iOS e como chegaríamos no resultado necessário em tão pouco tempo, para lançar um produto. O resultado dessas semanas foi decidir modularizar nosso projeto em pilares (Investimentos, Conta Digital, Cartões e Design System) e cada pilar ser um repositório diferente e ter o projeto principal fazendo a “integração” via Cocoapods.

Conseguimos em poucos meses criar esses novos pilares, dando autonomia para os times e velocidade de desenvolvimento, porém no longo prazo, isso trouxe problemas que serão abordado em breve 😃.

A medida que a empresa foi crescendo, nossas necessidades começaram a mudar. Assim que começamos a integrar mais bibliotecas em nosso aplicativo e ter desafios de novos apps, conceitos de white label foram trending topics na XP. No início nosso tempo de instalação do pod eram de 10~20 segundos e passou a ser de minutos já em 2021, por conta do nosso gráfico de dependências que se tornou complexo. O maior problema dessa abordagem de multi repositório, era garantir que todos atualizassem suas dependências e que bibliotecas externas estivessem padronizadas, sem falar da grande quantidade de códigos repetidos.

Hora da mudança

Planejar então o monorepo se tornou um dos principais objetivos para os engenheiros iOS, mesmo não sendo uma ideia muito nova, grandes empresas de tecnologia adotaram com grande sucesso, embora colocar todo seu código em um repositório possa ter suas desvantagens (quebras que afetam todos os times, desempenho, etc). As vantagens podem ser enormes, dependendo do fluxo de trabalho de desenvolvimento.

Quando começamos nosso esforço de modularização, consideramos adotar uma nova ferramenta de build system, porem isso seria muito complexo e teria um impacto muito grande, podendo se tornar um problema para a companhia e em nossa velocidade de entregar valor para o cliente final.

Foi aí que conseguimos padronizar e criar ferramentas para a criação de novos módulos, de maneira rápida e fácil, sem fugir do nosso gerenciador de dependências do Cocoapods.

Nossos resultados

Ainda não estamos onde queremos (sim queremos mudar nosso build system :D), porém nossos processos e números são muito melhores que antes e vou descrever um pouco deles aqui.

Processo simplificado de Git Flow, +60 engenheiros trabalhando de forma simples e com uma única branch principal (main).

Automações, esse tópico em especial é o meu preferido, detectar as mudanças no Pull Request, rodar o build desses módulos, garantir um quality gate separado e criar processos de upload de versões de desenvolvimento e releases candidates, deixaram o nosso processo bem robusto e traz uma visão excelente para quem está de fora poder acompanhar.

Code review, aqui o ganho foi extraordinário, imagina você ter a oportunidade de ter dezenas de pessoas avaliando o seu código, ou a oportunidade de aprender novas coisas apenas fazendo code review, isso eleva a maturidade das pessoas e garante que tenhamos menos ondulações em nossas curvas de aprendizado.

Tempo de Build, esse ainda esta longe de ser excelente, nosso projeto leva ~2 horas para que o build se torne uma versão disponível no TestFlight, porém quando comparamos com 1 dia inteiro no processo antigo é um salto e tanto, não é? 😎

Aqui merece uma explicação melhor desse 1 dia inteiro (em algumas ocasiões eram 2). Imagina seu time ter que fechar uma compilação da sua biblioteca, ter seu código mergeado na master e gerar o versionamento, após isso você ir no projeto principal e alterar manualmente seus apontamento de versão e então criar um Pull Request desse app principal. Isso era doloroso demais, tínhamos uma pessoa focada em Release Management e processos manuais. Repita isso para cada correção durante nosso processo de release candidate ☹️.

Conclusões

Mudar nossa estrutura de projeto trouxe diversos ganhos e ainda queremos mais. Entendemos que um build system para um projeto com +60 módulos (ainda é pouco se comparado à outras empresas) se faz necessário e ter ganhos de cache pode agilizar ainda mais nosso desenvolvimento. Queremos aproveitar os frutos dessa mudança e levar também para nosso time de engenheiros Android (estão no multi repositórios ainda) colher os mesmos frutos e avançar como uma estrutura de mobile de alto nível, levando a XPInc a ser comparadas com esses outros grandes players.

Quer se juntar ao nosso time? Estamos contratando