Introdução: Por que você precisa de CI/CD para projetos Swift?
O desenvolvimento para iOS e macOS exige uma alta cultura de código e confiabilidade. Cada alteração pode quebrar o build ou causar regressões nos testes. A verificação manual é um processo lento e pouco confiável. É aqui que o CI/CD (Continuous Integration / Continuous Deployment) entra em ação — integração e entrega contínuas.
GitHub Actions é uma ferramenta poderosa e integrada para automatizar fluxos de trabalho diretamente no seu repositório. Ele permite compilar o projeto automaticamente, executar testes, analisar o código e até publicar o aplicativo na App Store ou TestFlight a cada push ou criação de Pull Request.
Neste artigo, vamos detalhar como configurar um pipeline CI/CD completo para um projeto Swift no GitHub Actions. Você aprenderá como criar um workflow, configurar o build, a execução de testes, linting e deploy. Todos os exemplos de código estão prontos para uso.
Parte Principal
1. Fundamentos do GitHub Actions para Swift
GitHub Actions funciona com base em arquivos YAML, que são armazenados no diretório .github/workflows/. Cada arquivo descreve um ou mais workflows (fluxos de trabalho). Para um projeto Swift, precisaremos de um runner com macOS, pois a compilação de aplicativos iOS/macOS só é possível nesta plataforma.
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: swift build
- name: Run tests run: swift testVamos analisar os pontos-chave:
- on — gatilhos: execução em push e pull request na main.
- runs-on: macos-latest — usamos a versão mais recente do macOS para o runner.
- actions/checkout — action padrão para clonar o repositório.
- swift build e swift test — comandos do Swift Package Manager.
Este pipeline mínimo já garante uma verificação básica. Mas para um aplicativo iOS/macOS real, isso não é suficiente — é necessário configurar o Xcode, simuladores e dependências.
2. Configuração de build e testes para aplicativos iOS/macOS
Se o seu projeto usa Xcode (por exemplo, .xcworkspace ou .xcodeproj), o comando swift build não será adequado. Em vez disso, usamos xcodebuild. Também é necessário especificar o scheme e o destination (por exemplo, simulador de iPhone).
Exemplo de workflow para um aplicativo iOS:
name: iOS CI
on: push: branches: [ "develop", "main" ] pull_request: branches: [ "develop", "main" ]
jobs: test: runs-on: macos-14
steps: - uses: actions/checkout@v4
- name: Select Xcode version run: sudo xcode-select -s /Applications/Xcode_15.2.app
- name: Install CocoaPods (se você usa) run: pod install
- name: Build and Test run: | xcodebuild clean test \ -workspace YourApp.xcworkspace \ -scheme "YourApp Scheme" \ -destination 'platform=iOS Simulator,name=iPhone 15,OS=17.2' \ -resultBundlePath TestResults env: DEVELOPER_DIR: /Applications/Xcode_15.2.app/Contents/Developer
- name: Upload test results if: always() uses: actions/upload-artifact@v4 with: name: test-results path: TestResults.xcresultDetalhes importantes:
- macos-14 — usamos macOS 14 Sonoma com Xcode 15.2.
- xcode-select — especificamos explicitamente a versão do Xcode para evitar incompatibilidades.
- resultBundlePath — salvamos os resultados dos testes como um artefato para análise posterior.
-
Blogs
Book Recommendations
Leia também
Atualização de página via JavaScript: guia completo para iniciantes
MatFormFieldControl: entendendo o erro de uma vez por todas
Trabalhando com datas e horas em Go: guia completo
Trabalho com datas e horas em Go: técnicas avançadas e otimização
Cache em Go: Redis, Memcached e soluções embutidas: do A ao Z