Automatizando deploy e versionamento de aplicativos ios/android de forma efetiva

Introdução

Quando falamos de publicação de aplicações web ou backend, geralmente teremos uma versão de sandbox (pra testes) e uma de produção (o que é visto pelos usuários finais). Com isso, as versões finais rodam em servidores controlados totalmente pelas pessoas desenvolvedoras da equipe e podemos lançar novas versões em qualquer momento.

Para aplicações mobile, esse fluxo tende a ser um pouco complicado:
- Novas versões precisam ser aprovadas pelas lojas (google play e apple store). Isso implica que haverá uma demora entre o envio do app pra loja, aprovação, e publicação efetiva.
- O código do app roda diretamente no dispositivo do cliente e isso é mediado pela loja de aplicativos. O cliente pode inclusive não querer ou não poder fazer a atualização.

Além disso, existe uma grande complexidade ao gerenciar o fluxo de mútliplas versões, canais de distribuição e plataformas mobile. A má organização nesses processos causa diversos problemas como lentidão na equipe, má rastreabilidade de features/bugs e muito trabalho manual.

Nesse post vamos entender quais são os maiores desafios e apresentar nossa abordagem na equipe WhatsGood.

Glossário rápido

- Versão de Produção: A versão que efetivamente está pública e disponível aos usuários.
- Versão Beta: Canal de distribução que antecede a publicação em produção de fato. Essa versão já se conecta com todas as APIs de produção, logo os testes nessa versão são os mais aproximados do mundo real.
- Versão Sandbox: Canal de distribuição usado pra testes em um dispositivo físico. A versão de sandbox irá se conectar nas APIs de sandbox, portanto os testes nessa versão não afetam a versão de produção.
- Versão de Desenvolvimento: Essa versão contém o código mais atualizado do repositório (branch main/master) e todas as features e correções de bugs são feitas com base nessa versão.

Nossa organização

Nosso ciclo de versão se inicia após o “bump” de versão, que é o momento onde uma nova versão é gerada. Usamos versões numeradas para identificar cada versão, como `stable/51.x`, `stable/52.x` e assim sucessivamente.

Uma vez uma versão é gerada, ela é identificada como a versão de sandbox. Após os testes, essa mesma versão será promovida a versão beta, passará por novos testes e por fim será publicada em produção efetivamente.

O fluxo abaixo mostra o comportamento de cada versão ao longo de duas semanas:

Rastreabilidade

Uma grande vantagem dessa organização é uma alta rastreabilidade. Conseguimos saber exatamente quando determinadas mudanças entraram em determinadas versões.

Essa capacidade de rastreamento nos ajuda a identificar e corrigir bugs com mais agilidade, além da visibilidade de saber exatamente o que contém cada versão que está na mão dos usuários.

Para gerar esses release notes, usamos os webhooks do Github, em conjunto com nossa ferramenta interna de automações mobile (crave-tools).

Garantia de qualidade

Toda semana, num fluxo normal, produzimos 4 versões novas. Dois canais (sandbox, beta) X duas plataformas (iOS, android).

Com isso, apesar de termos alguns testes automatizados em cada plataforma, é importantíssimo termos uma verificação manual em cada uma dessas 4 versões. Isso garante que bugs e problemas serão encontrados antes de chegar ao usuário final.

O papel do backend e devops no time de mobile

Como mencionamos no começo, temos diversas versões mobile em produção, e com bastante frequência algum usuário estará usando alguma versão antiga do app por diversos motivos:
- Impossibilidade de atualizar: pode ser que o usuário use uma versão do sistema operacional que o app não suporta mais
- Falta de vontade de atualizar: é possível desabilitar as atualizações na loja de apps.

Com isso, os times de backend precisam estar preparados pra manter retrocompatibilidade com versões antigas do mobile, e pra isso podemos citar o versionamento de apis rest & testes automatizados. Isso vai evitar que o backend mude e quebre alguma feature em versões mais antigas.

Quando não for possível manter a retrocompatibilidade, o backend também pode controlar uma versão mínima necessária para o funcionamento dos apps e forçar o usuário a atualizar, caso seja necessário.

Tendemos a evitar essa abordagem de forçar a atualização dos apps, pois pode causar certa disrupção e perda de usuários. Como mencionamos, pode ser que o usuário não possa atualizar OU não queira. E forçar a atualização pode gerar incômodos e problemas.

Ferramentas utilizadas

- travis-ci: Responsável por CI/CD dos apps. Usamos o travis para rodar verificações (testes, linters) e também rodar o build dos apps e fazer o upload pras respectivas lojas.
- fastlane: Ferramenta de automação mobile, permite a integração direta com as lojas de apps.
- Github: Usamos o github como ferramenta de versionamento. Do github usamos bastante a parte de release notes e webhooks.
- Firebase App Distribution: Uma forma simples de distribuir as versões de sandbox para o time.
- crave-tools: Ferramenta interna usada para atualizar o contador de versões, além de disparar novos builds para o travisCI

Conclusão

Essa foi a forma que chegamos na equipe WhatsGood pra conseguir resolver toda essa complexidade usando boas práticas, ferramentas adequadas e muita automação. Sempre há melhorias no horizonte, tais como tornar o processo mais simples e mais tolerante a falhas, mas de modo geral, estamos contentes com esse modelo.

Nos conte nos comentários o que achou e confira nossas vagas para a equipe WhatsGood pelo link: https://apply.workable.com/whatsgood/