Aprimorando a entrega contínua de aplicativos iOS no Banco PAN

O processo de entrega continua é uma evolução natural e desafiadora para todo time de apps mobile. Vários pontos motivam as equipes para automatizar e melhorar esse processo: crescimento do produto (e da equipe), estabilidade do processo de release e confiança no controle de qualidade.

Na maioria dos times de mobile, aceitamos facilmente o tempo perdido que vem com cada ciclo de release. Aplicar técnicas e diferentes ferramentas, processos, correr atrás do pessoal de marketing para obter as releases notes atualizadas e solicitar as partes interessadas as aprovações necessárias. Em seguida com muito cuidado entrar na App Store Connect e no Play Console e configurar o lançamento do app.

A produtividade, a felicidade e a sanidade geral sofrem, mas todos aceitamos que esse “problema” é apenas o custo de trabalhar com lançamentos de aplicativos.

Aqui no Banco PAN sempre estamos buscando melhorar nossos processos e tentando automatizar os passos manuais que podem gerar algum erro humano, trazer mais tranquilidade, dar a sanidade mental das pessoas de volta e gerar ainda mais confiança no nosso processo de deploy de versões.

Baseado nisso, escrevi esse post para tentar mostrar como automatizar tudo isso tem deixado nosso deploy de versões mais robusto e estável, ganhos, desafios e passos futuros.

Um pouco de contexto

Em meados de outubro de 2021 começamos a implementar nosso CI mobile usando Azure Pipelines.

Até março desse ano (2022) fazíamos todo o processo de code review, geração de build, assinatura de binários (.ipa), ofuscação de código e envio para o Test Flight manualmente. Da mesma forma os engenheiros mobile nas squads geravam deploy de versões para QAs no App Center das squads também direto das suas máquinas.

Nosso foco e dedicação era tentar automatizar todos esses passos e remover todo esse trabalho manual, repetitivo, oneroso que é lidar com processos de release manualmente.

Nosso projeto

O App iOS do Banco Pan esta escrito em Swift e um modulo em Flutter foi adicionado em 2021 que é a nossa Loja Pan em parceria com a Mosaico. Com isso, de inicio, já tínhamos um desafio de conseguir compilar essas duas tecnologias, empacotar e assinar em um mesmo pacote. Precisaríamos de alguns scripts pra resolver esses problemas. 🔮

Azure Pipelines

Para quem não conhece como funciona a parte de pipelines da Azure, vou tentar resumir.

Esse assunto merece outro post. ;)

Partindo desse principio que a sua base de código esta no Github ou VSTS, por exemplo, basta adicionar um arquivo yml nomeando-o de azure-pipelines.ymlna pasta root do projeto e pronto. Simples assim.

O segundo ponto é customizar seu script de pipeline conforme suas necessidades. E é aqui que a mágica acontece! 🧙🏼‍♂️

De modo bem resumido o código acima:

trigger indica que sempre a pipeline vai iniciar quando houver um push na branch master.

pr indica que sempre que um pull request for aberto para a branch release/alguma-coisa a pipeline vai inciar também.

Ainda podemos adicionar parametros e/ou variáveis e usa-las durante a execução.

O pool é referente a versão do agent usado, no nosso caso, atualmente usamos o macOS-11.

Os steps serão as etapas da pipelines que deve ser executado. E ai vai de cada necessidade.

Processo de Release

Atualmente o nosso processo de deploy de novas versões do App iOS do Banco Pan é feita via Azure Pipelines. Desde da validação de Pull Request, até a disponibilização da versão para os QA’s e Beta Testers pelo Test Flight e App Center.

Code Review

Assim que as squads finalizam suas demandas (sprints), existe o processo de solicitar a inclusão dos novos arquivos na nossa base de código.

Para isso é aberto um Pull Request solicitando a revisão e validação do código em questão.

A partir desse momento nossa pipeline inicia o processo de build, execução dos testes e extração de métricas (que antes eram feitas manualmente).

Após o fim desse processo, a pipeline usa o Danger para automatizar algumas regras de code review e comentar no pull request mostrando o que esta ok, o que deve ser ajustado, alertas, testes que falharam e coverage dos testes unitários.

Smoke tests

Estando tudo ok, as novas mudanças serão aplicadas a nova versão e um novo PR será aberto para uma branch em especifico que faz o “trigger” da pipeline para gerar uma versão e iniciar os Smoke tests.

Esse tipo de teste, carinhosamente chamado de Testes Regressivos aqui no banco, trata-se de testes para estressar a versão que será, em um próximo passo, disponibilizada para os beta testers. Essa validação ainda é feita de forma manual com varias oportunidades de evolução no futuro próximo.

Integração Contínua

O CI configura o projeto, gera e assina o pacote em seguida cria o binário da nova versão.

O próximo passo executado pela pipeline é ofuscar a nossa base de código antes de enviar para a Test Flight, seja para os QAs, caso estejamos em fase de testes regressivos ou para os Beta Testers em ambiente de pré-produção.

Todas essas etapas eram manuais, o que onerava demais o tempo do engenheiro mobile, da maquina para fazer todo esse processo e ainda estava sujeito a falhas por conta, as vezes, de urgência para disponibilizar as novas alterações.

Atualmente a pipeline trabalha enquanto nós estamos no happy hour. 🥳🍻

Ainda temos várias oportunidades de evolução desse processo. Não basta somente ter as ferramentas, todo processo envolve bastante cultura, pessoas. Essas realmente é que fazem diferença em um processo de release confiante, estável e saudável.

Ganhos e resultados

Nos últimos 90 dias foram mais de 500 builds. 95% desses builds passaram ok na esteira. Tivemos falhas em menos de 5% desses jobs. Cada build de deploy de release durava em média 2h 33m no mac e o responsável pela deploy ficava com a máquina travada enquanto o processo era feito.

Com pipe, em 90 dias, entre versões de testes regressivos, beta testers e produção, foram mais 60 versões entregues, deixando o nosso time com mais capacidade de vazão nas tarefas, gerando ganhos de produtividade de 153 horas. Isso reflete diretamente na capacidade de entrega do time, investindo tempo em coisas que realmente faz sentido.

A adesão é crescente de todo o time: nos últimos 30 dias 7,83% do tempo da pipeline foi gerando versão para o App Center, há 60 dias atrás tínhamos menos de 5% do time usando a pipeline para gerar versão para o App Center.

Próximos passos

Como falei, processos de release são culturais. Pensando nisso nosso próximo passo é trabalhar uma rotina de deploy de versão conhecida de Release Train. Esse processo torna o deploy de novas versões mais constantes, além manter uma cadência de novas versões.

As release trains são comuns para produtos de grande escala porque são uma maneira muito mais fácil de sincronizar as demandas das squads. Ao invéz de ter uma data de lançamento alinhada com os prazos do produto de cada squad, são as próprias squads que precisam conciliar suas necessidades com o cronograma fixo da release train.

Às vezes, isso pode fazer com que as squads percam as releases se o trabalho atrasar, mas a consistência do processo, os benefícios para a segurança e a qualidade geral do produto o tornam uma abordagem ideal aos olhos da maioria das grandes empresas.

Outro ganho menos óbvio que os releases trains oferecem é que eles evitam que as squads tenham que lidar com manobras e “de acordos” sobre qual demanda vai chegar a determinada data ou se aguarda a demanda do vizinho para ter as duas na mesma versão.

Conclusão

Em última análise, apesar das práticas recomendadas semelhantes, grandes empresas sempre se adaptarão as especificidades de seu processo de lançamento de versão para atender às suas necessidades exclusivas. Mas, embora as técnicas possam ser diferentes entre as organizações, as estratégias mais impactantes que permitem que as equipes entreguem com sucesso um produto mobile em escala geralmente se enquadram em dois grandes grupos:

- Permitir ciclos de feedback orientados por dados (Firebase, Teste A/B, etc)

- Garantir lançamentos consistentemente com alta qualidade, aproveitando uma cadência de deploy regular e processo de estabilização robusto.

Tentar focar e trabalhar nessas áreas à medida que a equipe cresce — e à medida que a complexidade do produto aumenta — é uma grande vitória que vai trazer um ganho gigantesco. Mas não há solução pronta para uso, e atingir esses objetivos de maneira contínua e com o mínimo de stress não é algo garantido. Esse é o grande desafio para todos nós que trabalhamos com produtos móveis tentar resolver!

Até breve! ;)