CI/CD pour projets Swift : GitHub Actions de A à Z

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Introduction : Pourquoi le CI/CD est crucial pour le développement Swift

Dans le développement iOS/macOS moderne, la compilation et les tests manuels sont une source d'erreurs et de perte de temps. Chaque commit peut casser la build, et les tests sur des appareils réels nécessitent un accès physique. CI/CD (Intégration Continue / Déploiement Continu) résout ces problèmes en automatisant la compilation, les tests et le déploiement des applications.

GitHub Actions est un outil CI/CD intégré, parfaitement adapté aux projets Swift hébergés sur GitHub. Il permet de gratuitement (jusqu'à 2000 minutes par mois pour les dépôts publics) exécuter des workflows dans le cloud. Dans cet article, nous aborderons le cycle complet : de la configuration de base au déploiement sur l'App Store.

Pour qui est cet article ? Pour les développeurs iOS/macOS qui souhaitent automatiser les tâches répétitives et accélérer le cycle de publication. Même si vous êtes novice en DevOps, les instructions pas à pas et les exemples de code vous aideront à comprendre.

1. Bases de GitHub Actions pour Swift

1.1. Structure d'un workflow

GitHub Actions utilise des fichiers YAML stockés dans .github/workflows/. Chaque fichier représente un workflow (processus) distinct, déclenché par un événement (push, pull request, planification).

Un workflow de base pour un projet Swift ressemble à ceci :

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'

Points clés :

macos-latest — runner avec macOS, nécessaire pour Xcode et Swift.
actions/checkout@v4 — clonage du dépôt.
xcodebuild — commande pour la compilation et les tests.
Le paramètre destination spécifie le simulateur (remplacez-le par votre version iOS).

1.2. Mise en cache des dépendances

Swift Package Manager (SPM) est le gestionnaire de dépendances standard. Pour éviter de télécharger les paquets à chaque commit, utilisez la mise en 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

Cela réduit le temps de compilation de 40 à 60 %.

2. Configuration des tests et du linting

2.1. Tests unitaires et tests UI

Pour les projets iOS/macOS, il est essentiel d'exécuter les tests dans un simulateur. Assurez-vous que les tests sont activés dans le schéma Xcode. Exemple pour 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'

Pour iOS, ajoutez -destination 'platform=iOS Simulator,name=iPhone 15'. Important : les noms des simulateurs changent avec les versions de Xcode — utilisez xcrun simctl list pour vérifier les simulateurs disponibles.

2.2. Analyse statique (SwiftLint)

Maintenez la qualité du code avec SwiftLint. Ajoutez une étape dans le workflow :

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

Le flag --strict transforme les avertissements en erreurs — le workflow échouera si le code ne respecte pas les règles. Configurez .swiftlint.yml à la racine du projet.