Introducción: ¿Por qué necesitas CI/CD para proyectos Swift?
El desarrollo para iOS y macOS requiere una alta cultura de código y fiabilidad. Cada cambio puede romper la compilación o provocar regresiones en las pruebas. La verificación manual es un proceso lento y poco fiable. Aquí es donde entra en juego CI/CD (Integración Continua / Despliegue Continuo).
GitHub Actions es una herramienta potente e integrada para automatizar flujos de trabajo directamente en tu repositorio. Te permite compilar el proyecto automáticamente, ejecutar pruebas, analizar el código e incluso publicar la aplicación en App Store o TestFlight con cada push o creación de Pull Request.
En este artículo, analizaremos cómo configurar un pipeline CI/CD completo para un proyecto Swift en GitHub Actions. Aprenderás a crear un workflow, configurar la compilación, la ejecución de pruebas, el linting y el despliegue. Todos los ejemplos de código están listos para usar.
Parte principal
1. Fundamentos de GitHub Actions para Swift
GitHub Actions funciona con archivos YAML que se almacenan en el directorio .github/workflows/. Cada archivo describe uno o varios workflows (procesos de trabajo). Para un proyecto Swift, necesitaremos un runner con macOS, ya que la compilación de aplicaciones iOS/macOS solo es posible en esta plataforma.
Un workflow básico para un proyecto Swift se ve así:
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 testAnalicemos los puntos clave:
- on — disparadores: ejecución en push y pull request a main.
- runs-on: macos-latest — usamos la última versión de macOS para el runner.
- actions/checkout — action estándar para clonar el repositorio.
- swift build y swift test — comandos de Swift Package Manager.
Este pipeline mínimo ya proporciona una verificación básica. Pero para una aplicación iOS/macOS real, esto no es suficiente: es necesario configurar Xcode, los simuladores y las dependencias.
2. Configuración de la compilación y pruebas para aplicaciones iOS/macOS
Si tu proyecto usa Xcode (por ejemplo, .xcworkspace o .xcodeproj), el comando swift build no servirá. En su lugar, usamos xcodebuild. También es necesario especificar el esquema y el destination (por ejemplo, el simulador de iPhone).
Ejemplo de workflow para una aplicación 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 (si usas) 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.xcresultDetalles importantes:
- macos-14 — usamos macOS 14 Sonoma con Xcode 15.2.
- xcode-select — especificamos explícitamente la versión de Xcode para evitar incompatibilidades.
- resultBundlePath — guardamos los resultados de las pruebas como artefacto para su posterior análisis.
-
Blogs
Book Recommendations
Leer también
Mocks, stubs y fixtures en Swift: cómo probar sin dolor
Los 10 mejores frameworks de Java para desarrollo web: guía completa
API en PHP: REST, GraphQL y gRPC — ¿cuál elegir en 2025?
Los mejores IDE y herramientas para desarrollo en Rust en 2024
Pruebas E2E con TypeScript: Guía completa para desarrolladores