DEV Community

Lys
Lys

Posted on • Edited on

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

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
Enter fullscreen mode Exit fullscreen mode

Via Homebrew

brew install fastlane
Enter fullscreen mode Exit fullscreen mode

Depois de instalado, acesse seu diretório no terminal

cd your-ios-repo
Enter fullscreen mode Exit fullscreen mode

E inicialize o fastlane

fastlane init
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode
  • 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"
    )
Enter fullscreen mode Exit fullscreen mode

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"
        }
      }
    )
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

Descrição de um retorno de sucesso após rodar fastlane beta e a operação ter sido concluida com sucesso

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode
  • 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
Enter fullscreen mode Exit fullscreen mode
  • 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:

Imagem de status de sucesso do github actions depois de rodar a pipeline check_code e unit_test

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

Top comments (0)

Read next

midhunkrishnan profile image

To access terminal profile of VS Code and add commands to be run initially

Midhun Krishnan R -

pavitra_aravind_3d319916a profile image

Sample program using Encapsulation

Pavitra Aravind -

keploy profile image

How Fuzz Testing Saved A Software Company Millions?

keploy -

crusty-rustacean profile image

Rust: Decisions, Decisions

Jeff Mitchell -