Automatizando Testes e Distribuição de Apps iOS com Fastlane e GitHub Actions

Numa rotina de trabalho, é normal que algumas tarefas sejam automatizadas, como executar os testes quando um pull request é aberto, o processo de publicação para a app store, ou até de distribuição interna para beta testers (Test Flight, por exemplo)

Há algumas ferramentas para fazer esse processo, aqui usaremos o Fastlane, que vai automatizar o processo de distribuição com o TestFlight, e o Github Actions, que também usaremos para rodar os testes e um lint quando um pull request é aberto.

Pra dar tudo certo é importante que você tenha

• Xcode instalado na sua máquina local.

• Um repostório no Github com seu projeto iOS.

• Uma conta de desenvolvedor da Apple (Apple Developer account) e seu app preparado para gerar uma versão de teste.

Para instalar o Fastlane, há duas formas, via RubyGems, ou, se quiser evitar o uso do sudo ou o Ruby padrão do sistema, pode usar o Homebrew

Via RubyGems

sudo gem install fastlane -NV

Via Homebrew

brew install fastlane

Depois de instalado, acesse seu diretório no terminal

cd your-ios-repo

E inicialize o fastlane

fastlane init

Esse comando criará dois arquivos importantes, AppFile e Fastfile

Uso o VSCode para abrir e editar os próximos arquivos:

Mas uma dica para ver as pastas ocultas no finder é utilizar o comando Command + Shift + .

• Appfile

Simplifica o processo de configurar algumas variáveis essenciais que o Fastlane precisa saber, especialmente em casos de publicação e distribuição.

app_identifier "com.example.myapp" # The bundle identifier of your app
apple_id "example@apple.com" # Your Apple Developer Portal username

• Fastfile

É o arquivo que permite automatizar várias tarefas repetitivas em um projeto

Criaremos uma lane beta

• Uma lane é uma função no Fastlane que define um conjunto de tarefas ou ações a serem executadas. Você pode pensar em uma lane como um "workflow" ou "pipeline" de ações.

• Cada lane tem um nome, e você pode chamar essas lanes pelo nome no terminal (ex: fastlane ios beta).
  

default_platform(:ios)

platform :ios do
  desc "Builds the app and pushes to TestFlight"
  lane :beta do
    increment_build_number(
      xcodeproj: "ExampleApp.xcodeproj"
    )

A ação increment_build_number incrementa automaticamente o número do build, garantindo que cada nova versão tenha um número de build único.

    gym(
      scheme: "ExampleApp",
      export_method: "app-store",        
      clean: true,                                
      export_options: {
        provisioningProfiles: {
          "com.example.app" => "example_profile"
        }
      }
    )

A ação gym compila o projeto, gera o arquivo .ipa, e prepara o app para distribuição.
Também cuida da configuração do esquema correto, do método de exportação, e da limpeza do projeto.

    pilot(
      skip_waiting_for_build_processing: true,
      notify_external_testers: true,           
      api_key: app_store_connect_api_key(
        key_id: ENV['APP_STORE_CONNECT_API_KEY_ID'],
        issuer_id: ENV['APP_STORE_CONNECT_API_ISSUER_ID'],
        key_filepath: ENV['APP_STORE_CONNECT_API_KEY_FILE_PATH']
      )
    )
  end
end

A ação pilot faz o upload do arquivo .ipa diretamente para o TestFlight, sem precisar interagir com o Xcode. Ele pode pular o tempo de espera do processamento do build e notificar automaticamente os testadores externos.

Da primeira vez que configurei, não tinha adicionado a api_key e consegui normalmente, mas a partir da segunda vez, um erro de autenticação começou a aparecer no terminal, e era isso que estava faltando!

Esse ENV[''] representa uma variável de ambiente, você pode entender como criar aqui ou apenas deixar os valores expostos no código.

Depois de adicionar esses três passos, rode no terminal

fastlane beta

Se der tudo certo, o final do retorno de sucesso deve se parecer com isso:

Para mais informações, e saber quais tarefas mais o fastlane automatiza, você pode consultar a documentação.

Usando o Github Actions

Na raiz do projeto, crie uma pasta com o nome .github e dentro dela, uma outra chamada workflows.

mkdir -p .github/workflows

Como criaremos uma pipeline para quando um pull request for aberto, criaremos um arquivo com o nome on-pull-request.yml

name: Run CI
on:
  pull_request

• name

Define o nome do workflow. Ele é exibido no GitHub Actions quando o workflow é executado.

• on

Especifica os eventos que disparam a execução do workflow.

Aqui o workflow será acionado quando um pull request for aberto ou atualizado. Você pode especificar outros eventos, como push, schedule ou release, dependendo da necessidade.

jobs:
  check_code:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.0

      - name: Install Dependencies
        run: bundle install

      - name: Run SwiftLint
        uses: norio-nomura/action-swiftlint@3.2.1

  unit_test:
    runs-on: macos-14
    steps:
      - name: Setup xcode version
        uses: maxim-lobanov/setup-xcode@v1
        with:
          xcode-version: "15.0"

      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.0

      - name: Install Dependencies
        run: bundle install

      - name: Unit Testing
        run: bundle exec fastlane tests

• jobs

Cada job dentro do workflow representa um conjunto de tarefas que serão executadas, de forma paralela ou dependendo uma das outras, a depender de como estão configuradas.

Um job é composto de várias steps, que podem incluir ações predefinidas do GitHub, comandos shell (run), ou a execução de scripts personalizados.

• runs-on

Especifica o ambiente de execução (o sistema operacional) no qual o job será executado. Além do Ubuntu, também é possível especificar outros sistemas operacionais, como macos-latest ou windows-latest.

• steps

Define as etapas que serão executadas dentro de cada job. Cada etapa é uma ação individual ou comando que faz parte do job.

• uses

Refere-se a uma ação existente disponível no GitHub Marketplace ou uma ação definida localmente que você deseja executar em um step.

Aqui, está sendo usada uma ação predefinida do GitHub chamada checkout, que faz o checkout do repositório. A versão especificada é v3. Muitas vezes, essas ações são contribuições da comunidade ou do próprio GitHub.

• run

O comando run executa diretamente o que for especificado no terminal do ambiente. No exemplo acima, ele roda o comando gem install fastlane para instalar o Fastlane via RubyGems.

• with

Passa argumentos ou opções para uma ação usada em um step.

Ao abrir uma branch, commitar, dar push e abrir um pull request, os check's do seu pull request deve se parecer com isso:

Para mais informações e eventos que disparam a execução do workflow, consulte a documentação de eventos do Github Actions