CI/CD für Swift-Projekte: GitHub Actions von A bis Z

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 CI/CD für die Swift-Entwicklung entscheidend ist

In der modernen iOS/macOS-Entwicklung führen manuelle Builds und Tests zu Fehlern und Zeitverlust. Jeder Commit kann den Build zerstören, und Tests auf echten Geräten erfordern physischen Zugriff. CI/CD (Continuous Integration / Continuous Deployment) löst diese Probleme, indem es das Erstellen, Testen und Bereitstellen von Apps automatisiert.

GitHub Actions ist ein integriertes CI/CD-Tool, das sich ideal für Swift-Projekte eignet, die auf GitHub gehostet werden. Es ermöglicht kostenlose (bis zu 2000 Minuten pro Monat für öffentliche Repositories) Workflow-Ausführungen in der Cloud. In diesem Artikel behandeln wir den gesamten Zyklus: von der Basiskonfiguration bis zur Bereitstellung im App Store.

Für wen ist dieser Artikel? Für iOS/macOS-Entwickler, die Routineaufgaben automatisieren und den Release-Zyklus beschleunigen möchten. Selbst wenn Sie neu in DevOps sind – Schritt-für-Schritt-Anleitungen und Codebeispiele helfen Ihnen, sich zurechtzufinden.

1. Grundlagen von GitHub Actions für Swift

1.1. Workflow-Struktur

GitHub Actions verwendet YAML-Dateien, die in .github/workflows/ gespeichert werden. Jede Datei ist ein separater Workflow (Prozess), der durch ein Ereignis (Push, Pull Request, Zeitplan) ausgelöst wird.

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

Wichtige Punkte:

macos-latest – Runner mit macOS, erforderlich für Xcode und Swift.
actions/checkout@v4 – Klont das Repository.
xcodebuild – Befehl zum Erstellen und Testen.
Der Parameter destination gibt den Simulator an (ersetzen Sie ihn durch Ihre iOS-Version).

1.2. Abhängigkeiten-Caching

Swift Package Manager (SPM) ist der Standard-Abhängigkeitsmanager. Um Pakete nicht bei jedem Commit herunterladen zu müssen, verwenden Sie Caching:

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

Dies reduziert die Build-Zeit um 40–60%.

2. Einrichtung von Tests und Linting

2.1. Unit-Tests und UI-Tests

Für iOS/macOS-Projekte ist es entscheidend, Tests im Simulator auszuführen. Stellen Sie sicher, dass Tests im Xcode-Schema aktiviert sind. Beispiel für 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'

Für iOS fügen Sie -destination 'platform=iOS Simulator,name=iPhone 15' hinzu. Wichtig: Die Simulatornamen ändern sich mit den Xcode-Versionen – verwenden Sie xcrun simctl list, um die verfügbaren zu überprüfen.

2.2. Statische Analyse (SwiftLint)

Halten Sie die Codequalität mit SwiftLint aufrecht. Fügen Sie einen Schritt zum Workflow hinzu:

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

Das Flag --strict macht Warnungen zu Fehlern – der Workflow schlägt fehl, wenn der Code nicht den Regeln entspricht. Konfigurieren Sie .swiftlint.yml im Projektstammverzeichnis.