DE
RU
EN
ES
ZH
FR
PT
AR
HI
Ihr Swift-Projekt verdient einen automatischen Himmel: CI/CD von Grund auf aufbauen
\n\nSie haben ein cooles Swift-Paket oder eine App geschrieben. Der Code fliegt, die Tests laufen lokal, Sie fühlen sich wie ein Rockstar. Aber dann machen Sie einen Push – und der Albtraum beginnt: «Läuft es auch unter Linux?», «Bestehen die Tests unter macOS?», «Habe ich vielleicht vergessen, SwiftLint zu starten?».
\n\nKommt Ihnen das bekannt vor? Wenn ja, brauchen Sie eine CI/CD-Pipeline für Swift. Es ist wie ein Autopilot für Ihren Code: Er baut selbstständig, testet, prüft den Stil und deployed sogar. In diesem Artikel richten wir eine CI/CD-Pipeline für Swift von Grund auf am Beispiel von GitHub Actions ein. Sie erhalten fertigen, funktionierenden Code, den Sie kopieren und noch heute verwenden können.
\n\nSpoiler: Nach der Einrichtung erhalten Sie bei jedem Commit grüne Häkchen, anstatt vor der Konsole zu ergrauen.\n\n
Warum CI/CD für Swift kein Luxus, sondern eine Notwendigkeit ist
\n\nSwift lebt in zwei Welten: macOS (Xcode, CocoaPods, Carthage) und Linux (Vapor, SwiftNIO, Server-Projekte). Ohne CI/CD riskieren Sie:
\n\n- \n
- Einen Kompilierungsfehler auf einer anderen Plattform zu übersehen
- Den Linter nicht zu starten (und der Code sieht dann aus wie nach einem Bombenangriff)
- Stunden mit manuellem Deployment zu verschwenden
- Zeit mit der Suche nach Regressionen zu verlieren
Eine richtig konfigurierte Swift CI/CD-Pipeline löst all diese Probleme. Sie arbeitet 24/7, trinkt keinen Kaffee und sagt nicht «bei mir funktioniert es». Los geht's!
\n\nSchritt 1: Das Werkzeug auswählen – GitHub Actions
\n\nWir verwenden GitHub Actions – das ist das integrierte CI/CD in GitHub, und für Swift ist es ideal. Gründe:
\n\n- \n
- Kostenlos für öffentliche Repositories (2000 Minuten pro Monat)
- macOS-Runner – Build unter Xcode möglich
- Linux-Runner – für Server-Swift-Projekte
- Fertige Actions für SwiftLint, Tests, Deployment
Wenn Sie GitLab, Bitbucket oder Jenkins verwenden – die Prinzipien sind dieselben, aber die YAML-Syntax unterscheidet sich.
\n\nSchritt 2: Grundlegende Struktur einer CI/CD-Pipeline für Swift
\n\nJede Pipeline besteht aus drei Phasen:
\n\n- \n
- Build – Projekt-Build (SPM oder Xcode)
- Test – Ausführen von Unit-Tests
- Lint – Überprüfung des Codestils (optional, aber sehr empfehlenswert)
Zusätzlich kann ein Deployment hinzugefügt werden (z. B. auf einen Server oder in TestFlight).
\n\nDatei .github/workflows/swift-ci.yml erstellen
\n\nErstellen Sie im Stammverzeichnis Ihres Repositories den Ordner .github/workflows/ und darin die Datei swift-ci.yml. Hier ist eine minimale funktionierende Pipeline:
name: Swift CI/CD Pipeline\n\non:\n push:\n branches: [ main, develop ]\n pull_request:\n branches: [ main ]\n\njobs:\n build-and-test:\n runs-on: ubuntu-latest\n\n steps:\n - name: Checkout code\n uses: actions/checkout@v3\n\n - name: Setup Swift\n uses: swift-actions/setup-swift@v1\n with:\n swift-version: "5.9"\n\n - name: Build\n run: swift build\n\n - name: Run tests\n run: swift testDiese CI/CD-Pipeline für Swift wird bei jedem Push oder Pull Request in main/develop ausgelöst. Sie baut das Projekt und führt die Tests unter Ubuntu aus. Einfach? Ja. Aber lassen Sie uns etwas Magie hinzufügen.
\n\nSchritt 3: macOS und Xcode zur Build-Matrix hinzufügen
\n\nSwift-Entwickler arbeiten oft unter macOS, während der Server-Teil unter Linux läuft. Um sicherzustellen, dass das Projekt überall gebaut wird, verwenden wir eine Matrix-Strategie:
\n\njobs:\n build-and-test:\n strategy:\n matrix:\n os: [ubuntu-latest, macos-latest]\n swift-version: ["5.8", "5.9"]\n\n runs-on: ${{ matrix.os }}\n\n steps:\n - uses: actions/checkout@v3\n\n - name: Setup Swift\n uses: swift-actions/setup-swift@v1\n 
