GitHub Actions — was es ist, CI/CD-Pipelines und Automatisierung

Was ist GitHub Actions?

GitHub Actions ist eine in GitHub integrierte Workflow-Automatisierungsplattform, die 2019 gestartet wurde. Sie ermöglicht die Definition von CI/CD-Pipelines in YAML-Dateien, die direkt im Repository gespeichert werden. Jeder Workflow wird durch ein Ereignis ausgelöst: Push, Pull Request, Tag-Erstellung oder nach Zeitplan. Im Gegensatz zu Jenkins oder TeamCity ist keine separate Infrastruktur zum Hosten eines CI-Servers erforderlich.

Im Kontext der Mobilanwendungsentwicklung automatisiert GitHub Actions das Erstellen von APK und IPA, das Ausführen von Unit-Tests und UI-Tests auf Emulatoren, die Code-Überprüfung mit Lintern, das Signieren und Veröffentlichen im Google Play Store und App Store. Die Plattform bietet kostenlose Minuten für öffentliche Repositorys und für private je nach Tarif. Für Open-Source-Mobilprojekte ist dies eine vollwertige CI/CD-Lösung ohne Kosten.

GitHub Actions Architektur: Workflows, Jobs und Steps

Die GitHub Actions Architektur besteht aus vier Ebenen. Workflow ist die root YAML-Datei, die die Automatisierung definiert. Ein Workflow besteht aus Jobs, jeder Job wird auf einem separaten Runner ausgeführt. Innerhalb eines Jobs werden Steps ausgeführt — sequenzielle Befehle oder externe Actions. Events definieren die Auslöser: push, pull_request, schedule, workflow_dispatch. Ein Workflow kann auch manuell über den Actions-Reiter in der GitHub-Oberfläche ausgelöst werden.

GitHub bietet gehostete Runner mit vorinstallierten Betriebssystemen: Ubuntu, macOS und Windows. Für iOS-Builds ist ein macOS-Runner erforderlich, für Android — Linux oder macOS. Self-hosted Runner ermöglichen es, Jobs auf eigenen Servern mit einer benutzerdefinierten Umgebung auszuführen, was für große Projekte mit besonderen Hardwareanforderungen nützlich ist. GitHub unterstützt auch Self-hosted-Runner-Gruppen zur Organisation von Job-Ausführungswarteschlangen.

Struktur der Workflow-Datei

Eine grundlegende Workflow-Datei enthält Abschnitte: name, on (Auslöser), jobs. Jeder Job gibt runs-on (Runner-Typ), strategy (Matrix), steps (Aktionsliste) an. Steps können Shell-Befehle oder fertige Actions aus dem Marketplace sein, die über die Syntax owner/repo@version verbunden werden.

Mobile Anwendungen in GitHub Actions erstellen

Für Android-Builds umfasst ein Workflow typischerweise Schritte: Repository-Checkout, JDK-Installation, Gradle-Cache-Konfiguration, Ausführung von assembleRelease. Für iOS ist ein macOS-Runner erforderlich, Xcode-Installation über xcode-select, Provisioning-Profile-Auflösung und Ausführung von xcodebuild. Die Komplexität von iOS-Builds liegt im Code-Signing und Zertifikatsmanagement. Apple-spezifische Einstellungen umfassen die Verwaltung von Provisioning-Profilen über apple-actions/import-codesign-certs.

Die Matrix-Strategy ermöglicht das gleichzeitige Ausführen von Builds auf mehreren Versionen. Zum Beispiel: Matrix mit iOS-Versionen (15.0, 16.0, 17.0) und Xcode (14, 15). Dies beschleunigt die Überprüfung der Kompatibilität der Anwendung mit verschiedenen OS-Versionen, erhöht jedoch den Verbrauch von Runner-Minuten. Für Projekte mit begrenztem CI-Budget kann die Matrix auf Hauptkonfigurationen beschränkt werden.

Umgebung für Android einrichten

GitHub Actions bietet die setup-java-Action für die JDK-Installation und caching für das Cachen von Gradle. Das Android SDK ist bereits auf Ubuntu-Runnern vorinstalliert. Für benutzerdefinierte API-Level wird sdkmanager in einem separaten Schritt verwendet. Es wird empfohlen, separate Workflows für Android- und iOS-Builds zu erstellen, da sie unterschiedliche Runner und Build-Tools verwenden.

GitHub Marketplace und fertige Actions

Der GitHub Marketplace enthält über 15.000 Actions, die von der Community und offiziellen Entwicklern erstellt wurden. Für die Mobilanwendungsentwicklung umfassen die wichtigsten Kategorien: Code-Signing (apple-actions/import-codesign-certs), Tests (react-native-community/action), Deployment (google-github-actions/release-google-play), Benachrichtigungen (slackapi/slack-github-action). Actions für Firebase App Distribution, TestFlight-Upload und Fastlane sind ebenfalls verfügbar. Jede Action hat ein Kompatibilitätslabel für ein bestimmtes Runner-Betriebssystem.

Jede Action hat eine Version, Beschreibung, README und Lizenz. Bei der Auswahl einer Action sollten offizielle von Anbietern (Google, Apple, Microsoft) und über Verified Badge verifizierte bevorzugt werden. Es ist wichtig eine feste Hauptversion (actions/checkout@v4) anzugeben, nicht @main, um unerwartete Änderungen zu vermeiden. Wenn die benötigte Action nicht im Marketplace ist, können Sie eine benutzerdefinierte Action erstellen — lokal im Repository (Docker Action oder JavaScript Action) oder im Marketplace veröffentlichen.

Beliebte Actions für mobiles CI/CD

• actions/checkout — klont das Repository in den Runner
• actions/setup-java — installiert JDK für Android-Builds
• gradle/actions/setup-gradle — konfiguriert und cached Gradle
• apple-actions/import-codesign-certs — importiert Zertifikate für iOS
• google-github-actions/submit-release — veröffentlicht in der Google Play Console

Beispiel-Workflow für iOS-Projekt

Bei der Entwicklung von iOS-Anwendungen ist es wichtig, die korrekte Arbeit mit Simulatoren und Geräten einzurichten. Der macOS-14-Runner bietet eine Umgebung mit Rosetta 2 zum Ausführen von Intel-Builds auf ARM-Architektur. Ein Workflow kann mehrere Build-Schemata enthalten — Debug für Pull Requests und Release für Tags. GitHub Actions unterstützt xcresult-Parsing über die xcparse/sonarqube-Action zur Anzeige von Testergebnissen. Zum Senden von Build-Statusbenachrichtigungen kann eine Slack- oder Telegram-Action hinzugefügt werden.

Code-Signing für iOS erfordert den Import von Zertifikaten und Provisioning-Profilen. Apple-actions bieten einen Schritt zum Importieren eines P12-Zertifikats und Installieren eines Provisioning-Profils. Zertifikate werden als GitHub Actions Secrets gespeichert und erst in der Build-Phase entschlüsselt. Zur Signierungsautomatisierung wird Fastlane match verwendet, das als separater Schritt im Workflow aufgerufen werden kann.

Betrachten wir einen Workflow für eine iOS-App in Swift, der das Projekt erstellt, Tests ausführt und einen archivierten Build erstellt. Der Workflow verwendet macOS-14-Runner, Xcode 15.4 und Actions zur Zertifikatsverwaltung.

name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

Abhängigkeiten in GitHub Actions cachen

Caching reduziert die Build-Zeit, indem Abhängigkeiten zwischen Workflow-Läufen erhalten bleiben. GitHub bietet integriertes Caching über actions/cache. Für Gradle wird ~/.gradle gecached, für CocoaPods — Pods/, für SPM — .build/. Der Cache-Schlüssel enthält einen Hash der Abhängigkeitslistendatei — bei Änderung der Abhängigkeiten wird der Cache automatisch ungültig.

Besondere Aufmerksamkeit sollte der Cache-Wiederherstellungsstrategie (restore-keys) gewidmet werden. Wenn der genaue Schlüssel nicht gefunden wird, versucht GitHub Actions eine teilweise Übereinstimmung über restore-keys. Dies ist nützlich, wenn sich nur eine Abhängigkeit ändert — der Cache bleibt teilweise nutzbar. Für Gradle wird zusätzlich empfohlen, den Gradle Build Cache zu aktivieren, der Build-Ergebnisse zwischen verschiedenen Projektmodulen cached.

Beispiel für Gradle-Caching

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

Cache-Effizienz für Android-Projekte: erster Build ohne Cache — 8–12 Minuten, nachfolgender Build mit Cache — 2–4 Minuten. Für iOS mit CocoaPods ist die Einsparung ähnlich. Es wird empfohlen, actions/cache mit der setup-gradle-Action von Gradle für optimales Cache-Management zu kombinieren. Für npm-Abhängigkeiten in React Native wird actions/cache mit Hashing von package-lock.json verwendet. Bei richtiger Cache-Konfiguration kann die Build-Zeit um bis zu 70% reduziert werden.

GitHub Actions unterstützt Umgebungsvariablen auf Workflow-, Job- und Step-Ebene. Umgebungsvariablen können überschrieben werden: Step-Ebene hat höchste Priorität. Für vertrauliche Daten verwenden Sie immer Secrets — sie sind mit AES-256 verschlüsselt und werden nicht in Logs angezeigt. Umgebungsschutzregeln sind ebenfalls verfügbar — obligatorische manuelle Genehmigung vor dem Deployment. Für zusätzliche Sicherheit kann eine obligatorische Genehmigung von bestimmten Benutzern oder Teams konfiguriert werden.

GitHub Actions unterstützt auch Reusable Workflows — wiederverwendbare Pipelines, die aus anderen Workflows aufgerufen werden können. Dies ermöglicht die Erstellung eines zentralisierten Build-Workflows und dessen Wiederverwendung in allen Repositorys der Organisation. Ein Reusable Workflow wird mit einer einzigen Zeile aufgerufen und kann Eingabeparameter und Secrets akzeptieren. Dies ist besonders nützlich zur Standardisierung von CI/CD-Praktiken in großen Teams.

Sicherheit und bewährte Praktiken

Bei der Konfiguration von GitHub Actions für Mobilprojekte ist es wichtig, Sicherheitsprinzipien zu befolgen. OIDC (OpenID Connect) ermöglicht es, langlebige Anmeldeinformationen zu vermeiden und temporäre Tokens für Cloud-Anbieter zu erhalten. Verwenden Sie niemals Klartext-Secrets in Skripten — GitHub Actions maskiert Secrets automatisch in Logs.

Für Mobilprojekte ist es wichtig, den Workflow-Zugriff für Drittanbieter-Forks einzuschränken. Verwenden Sie die pull_request_target-Einstellung mit Vorsicht — sie führt Code aus dem Basis-Branch aus, nicht aus dem Fork. Für iOS-App-Code-Signing wird empfohlen, Zertifikate verschlüsselt zu speichern und sie erst in der Build-Phase über gpg oder openssl zu entschlüsseln.