Definindo workflows de projetos Android no Bitrise
O tempo é vital para qualquer projeto de desenvolvimento de software ⌛️, tarefas repetitivas como: executar testes unitários 🧪, gerar um executável do aplicativo 📦, publicá-lo para determinados usuários 🏁 podem ser gargalos quando realizado manualmente pelo desenvolvedor.
A ideia desse artigo é prover uma visão geral de como você pode otimizar o seu tempo utilizando Bitrise no desenvolvimento de aplicativos Android.
Ponto de Partida
Não existe receita de bolo, mas acredito que um bom ponto de partida é responder as seguintes questões:
- Qual é o sistema de versionamento adotado no meu projeto?
- Existem Pull Requests (PRs) no meu fluxo de trabalho? Alguém revisa meu código?
- Tenho uma branch base?
- Alguém precisa acessar o aplicativo para realizar testes?
- O aplicativo está publicado?
- Existe algum quadro de tarefas, ou sistema de tickets aonde atualizo o progresso de uma tarefa ou bug?
- Tenho testes unitários no projeto? Qual a periodicidade que preciso executar eles?
- Tenho algum arquivo de credenciais, como chaves ou tokens necessários para gerar o build do aplicativo?
Criação de Workflows no Bitrise
O Bitrise é uma ferramenta de CI/CD (Integração Contínua e Entrega Contínua) voltada para o desenvolvimento de aplicativos. Essa ferramenta possibilita ao desenvolvedor criar Workflows (fluxos de trabalho). Então, se você já tem as respostas para as questões anteriores, agora o próximo passo é criar no Bitrise Workflow(s) que atendam a sua necessidade 🚀
Vou apresentar aqui dois processos manuais de um projeto pessoal que automatizei utilizando Workflows do Bitrise.
Abrindo PR
O processo inicia quando o PR é aberto, caso ele seja aprovado, os testes unitários são executados e um executável é enviado para o Firebase App Distribution. O diagrama a seguir mostra as etapas organizadas:
Nesse processo manual é interessante identificar as ferramentas envolvidas:
- GitLab: aonde o repositório está hospedado;
- Firebase App Distribution: central de distribuição de builds.
A tarefa principal para automatizar esse Workflow é “ensinar” o Bitrise:
- aonde o repositório está hospedado;
- definir uma forma aonde ele possa “monitorar” cada vez que uma PR é aberta;
- criar o executável do aplicativo;
- distribuir o executável no Firebase App Distribution.
Ao criar um projeto no Bitrise você precisa inserir a URL do seu repositório, o tipo do seu projeto (no nosso caso Android). Provavelmente depois disso, você terá um Workflow template.
Nesse Workflow template precisamos definir uma trigger, quando o Workflow deve ser disparado. Para isso o Bitrise utiliza Webhooks que permitem executar uma lógica extra no servidor do GitLab (pode ser GitHub, Bitbucket, eles mantém o mesmo padrão de funcionamento). A imagem a seguir mostra uma trigger para cada PR aberto de uma branch qualquer (feature branchs) para a branch base (main).
Com isso, a cada vez que uma PR é aberta, o Workflow deverá ser acionado no servidor do Bitrise.
Toda vez que um Workflow inicia, o Bitrise precisa autenticar para acessar o repositório, para isso precisamos configurar uma chave SSH. Não se preocupe, a configuração da chave SSH você faz apenas uma vez 🤗.
Outro recurso interessante é o relatório de testes unitários, cada vez que os testes são executados. Dentro das opções do build, você consegue esse relatório:
A distribuição do executável no Firebase App Distribution requer a inclusão de uma nova Step. O Bitrise disponibiliza uma biblioteca de Steps para você enriquecer o seu Workflow:
Caso você precise atualizar um ticket no JIRA, por exemplo, você pode procurar por essa Step na biblioteca. As vezes você tem mais de um resultado, ampliando suas opções de escolha:
Automatizando com Workflow PR, agora consigo executar os testes cada vez que o PR é aberto e cada vez que realizo um commit novo na PR já aberta 🤗
Lançamento de Versão
O que difere o processo manual de Lançamento de Versão com o processo manual Abrindo PR é basicamente as tarefas:
- incrementar a versão;
- não executar testes unitários;
- distribuir a versão estável na Google Play para os usuários da faixa de testes.
Mas primeiro precisamos definir a trigger, quando podemos disparar esse Workflow? No meu caso será cada vez que realizo um commit na main branch (fecho uma PR).
O incremento da versão pode ser realizado com a Step:
Essa Step tem como saída duas variáveis ANDROID_VERSION_NAME e ANDROID_VERSION_CODE. Você pode adaptar o seu build.gradle pra capturar esses valores caso o build esteja rodando no Bitrise:
O Bitrise possui também uma Step para enviar o build do aplicativo para a Google Play:
Nessa Step é possível definir também a track aonde o aplicativo vai ser disponibilizado, no meu caso estou disponibilizando na track “beta”. É fundamental nessa Step você criar uma conta de serviço no Google Cloud, a partir disso você terá um arquivo JSON que permitirá que o Bitrise utilize essa conta para enviar builds para a Google Play.
Por fim, não menos importante…
Você tem um lugar no Bitrise para criar variáveis de ambiente e variáveis secretas:
Essas variáveis são sensíveis, então é legal você ter elas definidas no seu ambiente local (ignorado pelo Git) e no Bitrise. Assim, você consegue usar ambas de acordo com o ambiente que estiver gerando seu build.
Essas mesmas variáveis você pode expor para sua aplicação utilizando recursos do Gradle:
Conclusão
Automatizar tarefas que nos consomem tempo pode ser um desafio num primeiro momento, mas depois do esforço inicial para configuração dos Workflows, você verá que o tempo gasto no início será recuperado rapidinho 🙏.
A ideia desse artigo foi apenas dar uma visão geral, caso você esteja interessado em alguma Step específica, fica a vontade para comentar.
Eu estou a disposição de ajudar com links e materiais de consulta.
Valeu pessoal!
