Bitrise — Schlüsselkonzepte, Workflows und kontinuierliche Integration

Was ist Bitrise?

Bitrise ist eine 2016 gestartete CI/CD-Plattform, die sich vollständig auf die mobile Entwicklung konzentriert. Im Gegensatz zu universellen Lösungen wie GitHub Actions und GitLab CI wurde Bitrise ursprünglich für die Automatisierung von iOS- und Android-App-Builds entwickelt. Die Plattform läuft in der Cloud und bietet eigene gehostete Runner mit macOS und Linux. Bitrise unterstützt alle gängigen mobilen Stacks: Swift, Kotlin, Flutter, React Native, Cordova und Xamarin.

Der Hauptvorteil von Bitrise sind die vorkonfigurierten Step-Vorlagen für typische mobile Entwicklungsaufgaben: Xcode-Build, Gradle-Assemble, Fastlane, Firebase Distribution, TestFlight, Google Play. Das Einrichten der Pipeline dauert Minuten über den visuellen Editor, und die YAML-Konfiguration wird automatisch in der Datei bitrise.yml generiert. Für erfahrene Benutzer steht ein YAML-Editor mit Autovervollständigung zur Verfügung.

Bitrise-Architektur: Workflows und Steps

Die Bitrise-Architektur basiert auf zwei Schlüsselkonzepten: Workflow und Step. Ein Workflow ist eine Sequenz von Steps, die die Pipeline definiert. Jedes Projekt kann mehrere Workflows haben: primary (Haupt-Build), deploy (Veröffentlichung), test (nur Tests). Ein Workflow wird durch Ereignisse ausgelöst: Push, PR, Tag oder nach Zeitplan. Workflows können auch manuell über die Weboberfläche gestartet werden, was für Ad-hoc-Builds nützlich ist.

Ein Step ist ein atomares Modul, das eine einzelne Aufgabe ausführt. Steps können im visuellen Editor per Drag & Drop angeordnet werden, wobei Reihenfolge und Konfiguration geändert werden können. Bitrise stellt Steps für Xcode Archive & Export, Gradle Runner, CocoaPods Install, Firebase Distribution und Slack-Benachrichtigungen bereit. Die Community erstellt ebenfalls Steps — sie sind über die Step Library verfügbar. Jeder Step hat erforderliche und optionale Eingabeparameter sowie Ausgabevariablen, die von nachfolgenden Steps verwendet werden können.

Bitrise unterstützt das Konzept einer Pipeline — die Kombination mehrerer Workflows in einer einzigen Pipeline. Eine Pipeline kann primäre Builds für alle Plattformen und separate Workflows für Bereitstellung und Tests umfassen. Dies ermöglicht komplexe CI/CD-Prozesse, bei denen ein Build einen anderen auslöst. Bitrise Stacks bestimmen die vorinstallierte Software auf dem Runner: Xcode, Android SDK, Flutter, Node.js und andere Tools.

Beliebte Steps für mobile Projekte

• Xcode Archive & Export — Build und Export von IPA mit Provisioning-Profile-Verwaltung
• Gradle Runner — Ausführung von Gradle-Aufgaben mit Argumenten und Caching
• Flutter Build — Build von Flutter-Apps für iOS und Android
• Firebase App Distribution — Veröffentlichung von Builds für Tester
• Certificate and Profile Installer — automatische Installation von Code-Signing-Zertifikaten

Bitrise-Integration mit Git-Repositories

Bitrise integriert sich mit GitHub, GitLab, Bitbucket und Azure DevOps. Beim Verbinden eines Repositories erkennt Bitrise automatisch den Projekttyp (iOS, Android, Flutter) und schlägt eine Workflow-Vorlage vor. Für private Repositories fordert Bitrise Zugriff über OAuth oder SSH-Schlüssel an. Mehrere Repositories können mit einer einzigen Anwendung verbunden werden.

Nach der Verbindung erstellt Bitrise einen Webhook im Repository, um Builds bei Push und PR automatisch zu starten. Jeder Build erhält eine eindeutige Nummer, Logs und Artefakte. Die Oberfläche ermöglicht das Durchsuchen des Build-Verlaufs, den Vergleich von Änderungen und das Neustarten fehlgeschlagener Builds. Bitrise unterstützt auch geplante Builds für regelmäßige nächtliche Builds und die Integration mit Jira für das Commit-Tracking.

Code Signing und Veröffentlichung im App Store und Google Play

Code Signing für iOS ist eine der komplexesten CI/CD-Aufgaben, und Bitrise löst sie so einfach wie möglich. Die Plattform speichert Zertifikate und Provisioning Profiles verschlüsselt, installiert sie automatisch im entsprechenden Keychain vor dem Build und exportiert das signierte IPA. Der Step Certificate and Profile Installer lädt Dateien aus dem Bitrise-Speicher herunter und konfiguriert Xcode. Development-, AdHoc-, AppStore- und Enterprise-Zertifikatstypen werden unterstützt.

Für die Veröffentlichung im App Store Connect stellt Bitrise Steps zum Hochladen von IPA über Xcode Archive & Export bereit. Die Google Play-Veröffentlichung verwendet Gradle Runner mit Keystore-Signierung, wonach das APK/AAB über den Google Play Deploy Step in die Google Play Console hochgeladen wird. Für Firebase App Distribution genügt die Angabe des Firebase-Tokens und der Testergruppe. Bitrise automatisiert die Aktualisierung von Versionsnummer und Build-Nummer vor jeder Veröffentlichung.

Einrichtung von Code Signing in Bitrise

Zertifikate werden im Bereich Code Signing der Weboberfläche hochgeladen: P12 mit privatem Schlüssel, Provisioning Profile (.mobileprovision), Keystore (.jks/.keystore) für Android. Bitrise installiert automatisch iOS-Zertifikate bei jeder Workflow-Ausführung in den Keychain und exportiert die signierte Anwendung. Für Android genügt das Hochladen der Keystore-Datei — Bitrise übergibt sie während des Builds über Umgebungsvariablen an Gradle.

Beispielkonfiguration von Bitrise für Flutter

Betrachten wir einen Workflow für eine Flutter-Anwendung, der Builds für iOS und Android erstellt und veröffentlicht. Bitrise erkennt automatisch ein Flutter-Projekt und schlägt die entsprechenden Steps vor. Der Workflow umfasst Flutter-Installation, Pub-Cache-Caching, Build, Test und Bereitstellung. Für iOS-Builds werden zusätzlich Code-Signing-Zertifikate benötigt, die Bitrise automatisch lädt.

Beim Erstellen von Flutter-Apps unterstützt Bitrise separate Konfigurationen für jede Plattform. Android-Builds laufen auf einem Linux-Runner mit Flutter SDK, iOS auf einem macOS-Runner. Ein Workflow kann bedingte Steps enthalten: build_android und build_ios, die nur auf den jeweiligen Plattformen ausgeführt werden. Für React Native-Projekte bietet Bitrise einen ähnlichen Satz von Steps mit npm/nvm und Metro Bundler.

format_version: 13
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git

trigger_map:
- push_branch: main
  workflow: primary

workflows:
  primary:
    steps:
    - activate-ssh-key@4:
        run_if: true
    - git-clone@8: {}
    - flutter-installer@0:
        inputs:
        - version: 3.24.0
    - flutter-build@0:
        inputs:
        - platform: both
        - ios_output_type: archive
    - deploy-to-bitrise-io@2: {}

Benutzerdefinierter Step für die Bereitstellung

Nach dem Build kann ein Firebase App Distribution Step für iOS und Android hinzugefügt werden. Der Step akzeptiert firebase_token, app_id und testers_group. Bitrise setzt Werte aus Secrets ein — die sichere Token-Speicherung stellt sicher, dass sie nicht in Logs erscheinen.

- firebase-app-distribution@1:
    inputs:
    - firebase_token: $FIREBASE_TOKEN
    - app_id: $FIREBASE_IOS_APP_ID
    - testers_group: qa-team
    - release_notes: |
        Build $BITRISE_BUILD_NUMBER

Secrets und Umgebungsverwaltung

Die ordnungsgemäße Verwaltung vertraulicher Daten ist die Grundlage der Sicherheit von CI/CD-Prozessen. Bitrise Secrets werden verschlüsselt und sind nach dem Speichern nicht lesbar. Beim Erstellen einer neuen Anwendung bietet Bitrise an, Secrets aus einem anderen Projekt zu importieren oder manuell festzulegen. Für große Teams steht die Funktion Environment Groups zur Verfügung — zentrale Verwaltung von Variablen und Secrets für eine Gruppe von Anwendungen.

Bitrise bietet einen integrierten Secrets-Speicher für vertrauliche Daten: API-Schlüssel, Firebase-Tokens, Keystore-Passwörter, Apple ID. Secrets werden als Schlüssel-Wert-Paare in der Weboberfläche definiert und in Build-Logs maskiert. Sie sind auf Anwendungs- und Workflow-Ebene verfügbar. Secrets können nach dem Speichern nicht gelesen werden — sie können nur überschrieben werden.

Umgebungsvariablen (ohne Secret-Kennzeichnung) werden für die Konfiguration verwendet: Xcode-Version, Projektpfad, Build-Schema. Bitrise-Umgebungsvariablen (BITRISE_BUILD_NUMBER, BITRISE_APP_TITLE) liefern Metainformationen über den Build. Secrets werden im Ruhezustand verschlüsselt und nur auf dem Runner während der Workflow-Ausführung entschlüsselt. Für die Gruppenverwaltung von Variablen unterstützt Bitrise Environment Groups — Gruppen von Variablen, die gleichzeitig auf mehrere Anwendungen anwendbar sind.

Besondere Aufmerksamkeit verdient die iOS-Zertifikatsverwaltung über Bitrise. Die Plattform installiert automatisch P12 und Provisioning Profiles vor dem Build in den System-Keychain. Für Android wird die Keystore-Datei verwendet, die im Bereich Code Signing hochgeladen wird. Jede Zertifikatsdatei wird verschlüsselt gespeichert und nur während des Builds entschlüsselt.

Beispiel für die Verwendung von Secrets

- google-play-deploy@3:
    inputs:
    - package_name: com.example.app
    - service_account_json_key: $SERVICE_ACCOUNT_KEY
    - app_file: $BITRISE_APK_PATH

Bitrise Stacks und Umgebungen

Bitrise bietet verschiedene Stacks für Builds — vorinstallierte Images mit Tools und SDKs. Verfügbare Stacks umfassen Xcode (Versionen 14, 15, 16 mit iOS SDK 17, 18), Android (mit verschiedenen SDK- und NDK-Versionen), Flutter, React Native und Kotlin Multiplatform. Jeder Stack hat eine Beschreibung der vorinstallierten Tools und Versionen.

Die Stack-Auswahl beeinflusst die Build-Zeit und die Projektkompatibilität. Bitrise aktualisiert regelmäßig die Stacks und fügt neue Tool-Versionen hinzu. Eine bestimmte Stack-Version kann in bitrise.yml festgelegt werden, um unerwartete Änderungen bei Plattform-Updates zu vermeiden. Für benutzerdefinierte Abhängigkeiten wird der Script Step verwendet, der vor dem Haupt-Build notwendige Pakete installiert. Bitrise unterstützt auch Docker-Images für Linux-Stacks, was benutzerdefinierte Umgebungen für Android-Builds ermöglicht.