Pipeline CI/CD para Swift: configuração do zero no macOS e Linux

Seu projeto Swift merece um céu automatizado: construindo CI/CD do zero

Você escreveu um pacote ou aplicativo Swift incrível. O código voa, os testes passam localmente, você se sente uma estrela do rock. Mas basta dar um push — e o inferno começa: "E no Linux compila?", "E os testes no macOS passam?", "E se eu esqueci de executar o SwiftLint?".

Familiar? Se sim, você precisa de um pipeline CI/CD para Swift. É como um piloto automático para o seu código: ele mesmo compila, testa, verifica o estilo e até faz o deploy. Neste artigo, configuraremos um pipeline CI/CD Swift do zero usando o GitHub Actions como exemplo. Você receberá um código funcional pronto, que pode copiar e usar hoje mesmo.

Spoiler: após a configuração, você receberá marcas verdes a cada commit, em vez de ficar grisalho em frente ao console.

Por que CI/CD para Swift não é um luxo, mas uma necessidade

O Swift vive em dois mundos: macOS (Xcode, CocoaPods, Carthage) e Linux (Vapor, SwiftNIO, projetos de servidor). Sem CI/CD, você corre o risco de:

\n
• Perder um erro de compilação em outra plataforma
\n
• Esquecer de executar o linter (e depois o código parece que passou por um bombardeio)
\n
• Gastar horas com deploy manual
\n
• Perder tempo procurando regressões
\n

Um pipeline CI/CD Swift configurado corretamente resolve todos esses problemas. Ele funciona 24/7, não bebe café e não diz "mas aqui funciona". Vamos nessa!

Passo 1: Escolhendo a ferramenta — GitHub Actions

Usaremos o GitHub Actions — é o CI/CD integrado do GitHub, e é ideal para Swift. Motivos:

\n
• Gratuito para repositórios públicos (2000 minutos por mês)
\n
• Runners macOS — permite compilar com Xcode
\n
• Runners Linux — para projetos Swift de servidor
\n
• Actions prontas para SwiftLint, testes, deploy
\n

Se você usa GitLab, Bitbucket ou Jenkins — os princípios são os mesmos, mas a sintaxe YAML será diferente.

Passo 2: Estrutura básica do pipeline CI/CD para Swift

Qualquer pipeline consiste em três etapas:

\n
1. Build — compilação do projeto (SPM ou Xcode)
\n
2. Test — execução dos testes unitários
\n
3. Lint — verificação do estilo do código (opcional, mas altamente recomendado)
\n

Adicionalmente, pode-se adicionar deploy (por exemplo, para um servidor ou TestFlight).

Criando o arquivo .github/workflows/swift-ci.yml

Na raiz do seu repositório, crie a pasta .github/workflows/ e dentro dela o arquivo swift-ci.yml. Aqui está um pipeline funcional mínimo:

name: Swift CI/CD Pipeline\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n\n    steps:\n    - name: Checkout code\n      uses: actions/checkout@v3\n\n    - name: Setup Swift\n      uses: swift-actions/setup-swift@v1\n      with:\n        swift-version: "5.9"\n\n    - name: Build\n      run: swift build\n\n    - name: Run tests\n      run: swift test

Este pipeline CI/CD para Swift é executado a cada push ou pull request no main/develop. Ele compila o projeto e executa os testes no Ubuntu. Simples? Sim. Mas vamos adicionar um pouco de magia.

Passo 3: Adicionando macOS e Xcode à matriz de compilação

Desenvolvedores Swift geralmente trabalham no macOS, e a parte do servidor no Linux. Para ter certeza de que o projeto compila em todos os lugares, usamos a estratégia de matriz (matrix strategy):

jobs:\n  build-and-test:\n    strategy:\n      matrix:\n        os: [ubuntu-latest, macos-latest]\n        swift-version: ["5.8", "5.9"]\n\n    runs-on: ${{ matrix.os }}\n\n    steps:\n    - uses: actions/checkout@v3\n\n    - name: Setup Swift\n      uses: swift-actions/setup-swift@v1\n