CI/CD für Swift-Projekte: GitHub Actions Schritt-für-Schritt-Anleitung

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

Einleitung: Warum braucht man CI/CD für Swift-Projekte?

Die Entwicklung für iOS und macOS erfordert eine hohe Codekultur und Zuverlässigkeit. Jede Änderung kann den Build zerstören oder zu Regressionen in den Tests führen. Manuelle Überprüfung ist ein langsamer und unzuverlässiger Prozess. Hier kommt CI/CD (Continuous Integration / Continuous Deployment) ins Spiel – kontinuierliche Integration und Auslieferung.

GitHub Actions ist ein leistungsstarkes und integriertes Tool zur Automatisierung von Arbeitsabläufen direkt in Ihrem Repository. Es ermöglicht Ihnen, das Projekt automatisch zu bauen, Tests auszuführen, Code zu analysieren und sogar die App bei jedem Push oder Pull Request im App Store oder TestFlight zu veröffentlichen.

In diesem Artikel werden wir durchgehen, wie man eine vollwertige CI/CD-Pipeline für ein Swift-Projekt mit GitHub Actions einrichtet. Sie erfahren, wie Sie einen Workflow erstellen, Build, Testdurchlauf, Linting und Deployment konfigurieren. Alle Codebeispiele sind einsatzbereit.

Hauptteil

1. Grundlagen von GitHub Actions für Swift

GitHub Actions basiert auf YAML-Dateien, die im Verzeichnis .github/workflows/ gespeichert werden. Jede Datei beschreibt einen oder mehrere Workflows. Für ein Swift-Projekt benötigen wir einen Runner mit macOS, da das Bauen von iOS/macOS-Anwendungen nur auf dieser Plattform möglich ist.

Ein grundlegender Workflow für ein Swift-Projekt sieht so aus:

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 test

Lassen Sie uns die wichtigsten Punkte durchgehen:

on — Auslöser: Start bei Push und Pull Request in main.
runs-on: macos-latest — wir verwenden die neueste Version von macOS für den Runner.
actions/checkout — Standard-Action zum Klonen des Repositorys.
swift build und swift test — Befehle des Swift Package Managers.

Diese minimale Pipeline bietet bereits eine grundlegende Überprüfung. Aber für eine echte iOS/macOS-Anwendung reicht das nicht aus – man muss Xcode, Simulatoren und Abhängigkeiten konfigurieren.

2. Konfiguration von Build und Tests für iOS/macOS-Anwendungen

Wenn Ihr Projekt Xcode verwendet (z. B. .xcworkspace oder .xcodeproj), ist der Befehl swift build nicht geeignet. Stattdessen verwenden wir xcodebuild. Außerdem müssen das Scheme und das Destination (z. B. iPhone-Simulator) angegeben werden.

Beispiel-Workflow für eine iOS-Anwendung:

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 (falls verwendet)      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.xcresult

Wichtige Details:

macos-14 — wir verwenden macOS 14 Sonoma mit Xcode 15.2.
xcode-select — wir geben die Xcode-Version explizit an, um Inkompatibilitäten zu vermeiden.
resultBundlePath — wir speichern die Testergebnisse als Artefakt zur weiteren Analyse.
actions/upload-artifact — lädt die Testergebnisse hoch, auch wenn der Build fehlschlägt.