CI/CD para proyectos Swift: GitHub Actions de la A a la Z

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

Introducción: Por qué CI/CD es crítico para el desarrollo en Swift

En el desarrollo moderno de iOS/macOS, la compilación y las pruebas manuales son un camino hacia errores y pérdida de tiempo. Cada commit puede romper la compilación, y las pruebas en dispositivos reales requieren acceso físico. CI/CD (Continuous Integration / Continuous Deployment) resuelve estos problemas automatizando la compilación, las pruebas y el despliegue de aplicaciones.

GitHub Actions es una herramienta CI/CD integrada, ideal para proyectos Swift alojados en GitHub. Permite ejecutar flujos de trabajo en la nube de forma gratuita (hasta 2000 minutos al mes para repositorios públicos). En este artículo, desglosaremos el ciclo completo: desde la configuración básica hasta el despliegue en App Store.

¿Para quién es este artículo? Para desarrolladores de iOS/macOS que quieran automatizar tareas rutinarias y acelerar el ciclo de lanzamiento. Incluso si eres nuevo en DevOps, las instrucciones paso a paso y los ejemplos de código te ayudarán a entenderlo.

1. Fundamentos de GitHub Actions para Swift

1.1. Estructura de un workflow

GitHub Actions utiliza archivos YAML que se almacenan en .github/workflows/. Cada archivo es un workflow (proceso) independiente que se activa mediante un desencadenante (push, pull request, programación).

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: 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'

Puntos clave:

macos-latest — runner con macOS, necesario para Xcode y Swift.
actions/checkout@v4 — clona el repositorio.
xcodebuild — comando para compilar y probar.
El parámetro destination especifica el simulador (reemplázalo con tu versión de iOS).

1.2. Almacenamiento en caché de dependencias

Swift Package Manager (SPM) es el gestor de dependencias estándar. Para evitar descargar paquetes en cada commit, utiliza el almacenamiento en caché:

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

Esto reduce el tiempo de compilación entre un 40 y un 60%.

2. Configuración de pruebas y linting

2.1. Pruebas unitarias y pruebas de UI

Para proyectos de iOS/macOS, es fundamental ejecutar pruebas en el simulador. Asegúrate de que las pruebas estén habilitadas en el esquema de Xcode. Ejemplo 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, añade -destination 'platform=iOS Simulator,name=iPhone 15'. Importante: los nombres de los simuladores cambian con las versiones de Xcode; usa xcrun simctl list para verificar los disponibles.

2.2. Análisis estático (SwiftLint)

Mantén la calidad del código con SwiftLint. Añade un paso al workflow:

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

La bandera --strict convierte las advertencias en errores; el workflow fallará si el código no cumple con las reglas. Configura .swiftlint.yml en la raíz del proyecto.