CI/CD para projetos Swift: GitHub Actions do A ao Z

Introdução: Por que CI/CD é crítico para o desenvolvimento Swift

No desenvolvimento moderno de iOS/macOS, compilação e testes manuais são um caminho para erros e perda de tempo. Cada commit pode quebrar a build, e testar em dispositivos reais requer acesso físico. CI/CD (Continuous Integration / Continuous Deployment) resolve esses problemas automatizando a compilação, os testes e a implantação de aplicativos.

GitHub Actions é uma ferramenta CI/CD integrada, ideal para projetos Swift hospedados no GitHub. Ele permite executar workflows em nuvem gratuitamente (até 2000 minutos por mês para repositórios públicos). Neste artigo, abordaremos o ciclo completo: da configuração básica à implantação na App Store.

Para quem é este artigo? Para desenvolvedores iOS/macOS que desejam automatizar tarefas rotineiras e acelerar o ciclo de lançamento. Mesmo que você seja iniciante em DevOps — instruções passo a passo e exemplos de código ajudarão a entender.

1. Fundamentos do GitHub Actions para Swift

1.1. Estrutura do workflow

GitHub Actions usa arquivos YAML armazenados em .github/workflows/. Cada arquivo é um workflow (processo) separado que é acionado por um gatilho (push, pull request, agendamento).

Um workflow básico para um projeto Swift se parece com isso:

name: Swift CI

on:  push:    branches: [ main ]  pull_request:    branches: [ main ]

jobs:  build_and_test:    runs-on: macos-latest    steps:      - uses: actions/checkout@v4      - name: Build        run: xcodebuild build -project MyApp.xcodeproj -scheme MyApp -sdk iphonesimulator -destination 'platform=iOS Simulator,name=iPhone 15,OS=17.2'      - name: Test        run: xcodebuild test -project MyApp.xcodeproj -scheme MyApp -sdk iphonesimulator -destination 'platform=iOS Simulator,name=iPhone 15,OS=17.2'

Pontos-chave:

• macos-latest — runner com macOS, necessário para Xcode e Swift.
• actions/checkout@v4 — clonagem do repositório.
• xcodebuild — comando para compilar e testar.
• O parâmetro destination especifica o simulador (substitua pela sua versão do iOS).

1.2. Cache de dependências

Swift Package Manager (SPM) é o gerenciador de dependências padrão. Para evitar baixar pacotes a cada commit, use cache:

steps:  - uses: actions/cache@v3    with:      path: ~/Library/Developer/Xcode/DerivedData      key: ${{ runner.os }}-spm-${{ hashFiles('**/Package.resolved') }}      restore-keys: |        ${{ runner.os }}-spm-  - run: swift build

Isso reduz o tempo de compilação em 40–60%.

2. Configuração de testes e linting

2.1. Testes unitários e testes de UI

Para projetos iOS/macOS, é crítico executar testes no simulador. Certifique-se de que os testes estão habilitados no esquema do Xcode. Exemplo para macOS:

jobs:  test_macos:    runs-on: macos-latest    steps:      - uses: actions/checkout@v4      - name: Run macOS tests        run: xcodebuild test -project MyApp.xcodeproj -scheme MyApp -sdk macosx -destination 'platform=macOS,arch=x86_64'

Para iOS, adicione -destination 'platform=iOS Simulator,name=iPhone 15'. Importante: os nomes dos simuladores mudam com as versões do Xcode — use xcrun simctl list para verificar os disponíveis.

2.2. Análise estática (SwiftLint)

Mantenha a qualidade do código com SwiftLint. Adicione uma etapa ao workflow:

- name: SwiftLint  run: |    brew install swiftlint    swiftlint --strict

A flag --strict transforma avisos em erros — o workflow falhará se o código não estiver em conformidade com as regras. Configure o .swiftlint.yml na raiz do projeto.

3. Compilação e assinatura para implantação

3.1. Gerenciamento de certificados e perfis