Integração contínua do Android

Como podem os programadores Android garantir a qualidade do seu código num repositório partilhado?

O que é a integração contínua

A integração contínua (IC) é uma das melhores e mais importantes práticas profissionais na indústria do desenvolvimento de aplicações móveis. Permite aos programadores automatizar o seu processo de integração e assegura que o desenvolvimento de software cumpre os padrões de qualidade exigidos.

Por outras palavras, sempre que alguém submete código, o Android Seamless Integration cria e executa automaticamente testes unitários no servidor e notifica-o instantaneamente de quaisquer erros (também o notifica de construções bem sucedidas) antes de qualquer fusão. Isto é óptimo, não é?

O que é a entrega contínua?

A entrega contínua (CD) é a parte mais interessante para mim. Facilita a vida aos criadores e implementa automaticamente novas versões para testes ou produção na Play Store. Assegura que qualquer dos desenvolvimentos no processo de CI se encontra num estado facilmente implementável.

Com este exemplo veremos como podemos implementar uma integração contínua para um projecto Android usando Fastlane e GitlabCI.

Estes são os passos que iremos seguir neste post:

• Integração Fastlane, configuração Fastfile e definição de todas as pistas que necessitaremos mais tarde
• Criação do ficheiro .gitlab-ci.yml e definição de estágios e trabalhos
• Registo de canais para o nosso projecto
• Enviar algo para o repositório e ver o ativo a funcionar

Nota: Assumimos que está familiarizado com o processo de criação de uma aplicação Android, que pode escrever e executar testes localmente, e que está familiarizado com os princípios básicos da interface de utilizador do GitLab UI.

Como podemos automatizar as nossas tarefas

Para alcançar o objectivo, utilizaremos Fastlane: uma plataforma de código aberto escrita em Ruby que automatiza as tarefas mais aborrecidas com alguns comandos. Fastlane trata de quase tudo, desde a manipulação de capturas de ecrã, criação da aplicação, execução de testes unitários e da interface do utilizador, gestão de versões de construção, carregamento de um build na Firebase ou para produção na PlayStore, e muito mais. Neste post, cobriremos apenas alguns deles.

Tem um grande número de empregados; por conseguinte, podemos encontrar muitos complementos que podem ser utilizados para poupar tempo: https://fastlane.tools

Estes são os passos para configurar o Fastlane:

• Instalar as últimas ferramentas de linha de comando Xcode: xcode-select --install​
• Instalar Fastlane. Há duas opções: usando o RubyGems: sudo gem install fastlane -NV e usando o homebrew: brew install fastlane
• Navegamos para o nosso directório de projectos e iniciamos o Fastlane com a seguinte linha de comando:​ cd project_path e fastlane init

Ser-nos-á pedido que forneçamos as seguintes informações:

• O nome do pacote de candidatura quando solicitado (por exemplo, com.myapp.example)
• Pressionamos enter quando nos é pedido o itinerário para o ficheiro secreto json
• Responda 'n' quando lhe perguntarem se pretende enviar informação para o Google Play através do Fastlane (podemos configurar isto mais tarde)

E está tudo! O Fastlane irá gerar automaticamente uma configuração baseada na informação fornecida.

Nesta etapa pode ver o directório ./fastlane recentemente criado e os seguintes ficheiros:

• GemFile: Defina as nossas instalações em Fastlane. Isto irá definir claramente a versão de Fastlane utilizada e as suas dependências, bem como acelerar a sua utilização. Note que cada vez que adicionamos uma jóia a este ficheiro, devemos executar o seguinte comando: bundle install. Vamos acrescentar o seguinte gems:

• Appfile: define a informação de configuração global para a aplicação. Não editamos este ficheiro.

• Fastfile: que define as "pistas" que guiam o comportamento da linha rápida. Fastfile é o mais importante, uma vez que contém todas as pistas para as nossas necessidades.

O que é uma lane?

A Fastlane agrupa diferentes acções em lanes. Uma faixa começa com instrução lane :nombre, onde nombre é o nome dado a uma lane.

No nosso Fastfile, temos as seguintes lanes:


Unit_tests: Realizar testes unitários
Ui_tests_on_emulator: Realizar testes da interface do utilizador no emulador já instalado
Ui_tests_on_firebase_testlab: Executar UITests no Firebase TestLab
Build: criar o projecto
Firebase:  implementa uma versão no Firebase

Devemos começar a escrever todos os scripts a partir do zero?
A resposta é não, a menos que queira escrever várias linhas de código... Usaremos os Fastlane plugins.

Fastlane plugins

Para uma acção específica, tal como iniciar o emulador ou carregar uma versão, não precisamos de qualquer desenvolvimento adicional. Fastlane tem vários add-ons que podemos acrescentar ao nosso projecto.

Mais informação aqui: https://docs.fastlane.tools/plugins/available-plugins/

Aqui está um exemplo dos plug-ins que utilizei neste Fastfile:

• Lança o emulador para testes de interface de utilizador:

Pode ser feito numa linha simplesmente adicionando este plug-in: https://github.com/elloyg/fastlane-plugin-avd_emulator.

• Executa testes UI no Firebase TestLab para testar a nuvem:

Esta é uma opção interessante se quiser executar testes na nuvem em múltiplos dispositivos com diferentes configurações personalizáveis: https://github.com/cats-oss/fastlane-plugin-firebase_test_lab_android 

• Implementar uma versão beta de teste na Firebase

Também pode ser feito numa linha de código com uma configuração para as notas de lançamento e os testadores com quem deseja partilhar o lançamento: https://firebase.google.com/docs/app-distribution/android/distribute-fastlane.



Como posso testar as minhas lanes?

Para garantir que as nossas lanes funcionam correctamente, podemos testá-las separadamente usando o seguinte comando (note que deve colocá-las na raiz da pasta do projecto): bundle exec fastlane name_of_the_lane.



Vejamos o poder do que temos feito até agora. Imagine que está ocupado a desenvolver uma nova funcionalidade e quer partilhar uma compilação com um colega. Pode simplesmente percorrer a pista específica em dois segundos. Isso é óptimo!

As minhas pistas estão a funcionar, como podem funcionar automaticamente?

Estas pistas devem ser geridas automaticamente pelo GitLab CI. Embora eu saiba que estamos a falar de muitos conceitos, acredite-me, a combinação deles salvará a sua vida!


Gitlab CI/CD ​

Gitlab CI / CD é uma maravilhosa solução de integração contínua do GitLab. O serviço GitLab CI (integração contínua) é uma parte que cria e testa o software cada vez que um programador submete código a uma aplicação.

O CD GitLab CI (Continuous Implementation) é a parte que introduz alterações a todo o código em produção, resultando na implementação da produção diária.



GitLab CI é baseado num ficheiro .gitlab-ci.yml que será orquestre no nosso repositório.

Mas espere, o que é .gitlab-ci.yml?

O ficheiro .gitlab-ci.yml é onde se configura o que a CI faz com o seu projecto. Vive na raiz do seu repositório.
Em qualquer ponto do seu repositório, GitLab procurará o ficheiro .gitlab-ci.yml e começará a trabalhar em Runners de acordo com o conteúdo do ficheiro.

Precisamos de criar um ficheiro chamado .gitlab-ci.yml na raiz do repositório.



O conteúdo do ficheiro é o seguinte .gitlab-ci.yml:

Não devemos confundi-lo com as novas palavras (jobs, stages...), aqui está uma explicação de cada detalhe:

• Job: bloco de scripts a ser executado, pode ser uma tarefa de construção, uma tarefa de teste ou uma tarefa de implementação. Dependendo das nossas necessidades, cada trabalho irá realizar uma tarefa específica. Cada trabalho contém um ou mais guiões.
• Stages: Cada trabalho pertence a uma única fase. Uma fase pode conter zero, um ou mais trabalhos a serem executados. Todos os trabalhos numa única fase são realizados em paralelo. A fase seguinte só será realizada se todos os trabalhos da fase anterior forem completados correctamente ou se forem marcados como falhados. Se quiser permitir que um trabalho falhe e passar à fase seguinte, marque o trabalho com: allow_failure: true.​ ​​
• Script:  O bloco de scripts que será executado para o trabalho.
• ​Tags: São utilizados para seleccionar corredores específicos da lista de todos os corredores que podem executar este projecto.

•  Artifacts: Os artefactos de trabalho são uma lista de ficheiros e directórios criados por um trabalho após a sua conclusão. Esta característica é activada por defeito em todas as instalações do GitLab. Os artefactos de trabalho criados pelo GitLab Runner são carregados no GitLab e podem ser descarregados como um único ficheiro usando a interface de utilizador do GitLab ou a API do GitLab. Precisamos de fornecer o caminho para estes ficheiros com um certo nome.

Nota: Neste exemplo, as fases de "compilação" e "teste" serão executadas sempre que houver uma alteração no repositório (código submetido, fusão...), no entanto, a fase de "implementação" será executada quando fizermos um pedido de fusão. Este é apenas um cenário simples, pode definir como e quando gerir as faixas de rodagem, de acordo com as suas necessidades.

Quem vai gerir estes Jobs?

A resposta é o Runner. Esta é uma instância de construção usada para executar trabalhos em múltiplas máquinas e enviar os resultados para o GitLab. Pode ser colocada em utilizadores, servidores e máquinas locais separados.

Estes são os passos para configurar o seu próprio Runner específico.

Instalar o Runner:​

• ​​Instale o Runner usando brew: brew install gitlab-runner
• Instalar o Runner como um serviço e inicia-lo: brew services start gitlab-runner 
• Uma vez que se instala o Gitlab Runner, deve registá-lo com Gitlab CI.

- Registo de Runners na CI de Gitlab:

• Executar a seguinte linha de comando: gitlab-runner register

• O URL e a ficha podem ser obtidos a partir da seguinte rota:

​Gitlab Repository >Settings > CI/CD > Expand Runner Section > Specific runners

• O tag é utilizada para identificar o Runner. Podemos combinar um trabalho com um Corredor usando a etiqueta, por exemplo, se um trabalho tiver uma etiqueta "BABEL", no cano, esse trabalho será feito com o Corredor que tem a etiqueta "BABEL";
• Para o executor, escolheremos 'shell' para executar os guiões na nossa shell local. Esta é a maneira mais fácil.
• Agora, se voltarmos aos Runners na configuração (Gitlab Repository >Settings > CI/CD > Expand Runner Section > Specific runners) veremos o Runner recém-criado com o estado activo (verde).

Parabéns

Chegámos ao fim! Já está tudo feito! Após uma mudança no repositório (um novo pedido, actualização, pedido de fusão...), será activada uma pipeline. Um pipeline é um pacote para todos os trabalhos e fases. Realizará todos os trabalhos nas suas fases na ordem correcta.

Verá todos os oleodutos na secção dos pipelines:
Gitlab Repository > CI/CD > Pipelines



Clique num pipeline para ver os detalhes dos jobs:



Se tiver ocorrido um problema, o pipeline falhará e notificará os developers, aqui está um exemplo:


E acabou!

Espero que tenha gostado deste post, se tiver alguma dúvida, não hesite em contactar-me.

Happy coding!  :)