Bitrise — kluczowe pojęcia, Workflows i ciągła integracja

Czym jest Bitrise?

Bitrise to platforma CI/CD uruchomiona w 2016 roku, w pełni skoncentrowana na tworzeniu aplikacji mobilnych. W przeciwieństwie do uniwersalnych rozwiązań GitHub Actions i GitLab CI, Bitrise od początku została zaprojektowana do automatyzacji budowania aplikacji iOS i Android. Platforma działa w chmurze i udostępnia własne hostowane runnery z macOS i Linux. Bitrise obsługuje wszystkie popularne stosy mobilne: Swift, Kotlin, Flutter, React Native, Cordova i Xamarin.

Główną zaletą Bitrise są wstępnie skonfigurowane Step templates do typowych zadań tworzenia aplikacji mobilnych: Xcode build, Gradle assemble, Fastlane, Firebase Distribution, TestFlight, Google Play. Konfiguracja pipeline zajmuje minuty dzięki edytorowi wizualnemu, a konfiguracja YAML jest generowana automatycznie w pliku bitrise.yml. Dla zaawansowanych użytkowników dostępny jest edytor YAML z autouzupełnianiem.

Architektura Bitrise: Workflows i Steps

Architektura Bitrise opiera się na dwóch kluczowych pojęciach: Workflow i Step. Workflow to sekwencja Steps określająca pipeline. Każdy projekt może mieć kilka Workflows: primary (główna budowa), deploy (publikacja), test (tylko testy). Workflow uruchamiany jest przez triggery: push, PR, tag lub zgodnie z harmonogramem. Workflow można uruchomić ręcznie z interfejsu webowego, co jest przydatne do ad-hoc buildów.

Step to atomowy moduł wykonujący jedno zadanie. Kroki można przeciągać w edytorze wizualnym, zmieniać ich kolejność i konfigurację. Bitrise udostępnia Steps dla Xcode Archive & Export, Gradle Runner, CocoaPods Install, Firebase Distribution, powiadomień Slack. Społeczność również tworzy Steps — są one dostępne przez Step Library. Każdy Step ma obowiązkowe i opcjonalne parametry wejściowe oraz zmienne wyjściowe, które mogą być używane przez kolejne Steps.

Bitrise obsługuje koncepcję Pipeline — połączenie wielu Workflows w jeden pipeline. Pipeline może obejmować główną budowę dla wszystkich platform oraz osobne workflow do wdrażania i testowania. Umożliwia to tworzenie złożonych procesów CI/CD, gdzie jedna budowa uruchamia następną. Stacks Bitrise określają preinstalowane oprogramowanie na runnerze: Xcode, Android SDK, Flutter, Node.js i inne narzędzia.

Popularne Steps dla projektów mobilnych

• Xcode Archive & Export — budowanie i eksport IPA z zarządzaniem provisioning profile
• Gradle Runner — uruchamianie zadań Gradle z argumentami i buforowaniem
• Flutter Build — budowanie aplikacji Flutter dla iOS i Android
• Firebase App Distribution — publikowanie budowy dla testerów
• Certificate and Profile Installer — automatyczna instalacja certyfikatów code signing

Integracja Bitrise z repozytoriami Git

Bitrise integruje się z GitHub, GitLab, Bitbucket i Azure DevOps. Po podłączeniu repozytorium Bitrise automatycznie wykrywa typ projektu (iOS, Android, Flutter) i proponuje szablon Workflow. Dla repozytoriów prywatnych Bitrise żąda dostępu przez OAuth lub klucz SSH. Obsługiwane jest podłączenie wielu repozytoriów do jednej aplikacji.

Po podłączeniu Bitrise tworzy webhook w repozytorium do automatycznego uruchamiania budów przy push i PR. Każda budowa otrzymuje unikalny numer, logi i artefakty. Interfejs umożliwia przeglądanie historii budów, porównywanie zmian i ponowne uruchamianie nieudanych buildów. Bitrise obsługuje również scheduled builds do regularnych nocnych budów oraz integrację z Jira do śledzenia commitów.

Code Signing i publikacja w App Store i Google Play

Code signing dla iOS to jedno z najtrudniejszych zadań CI/CD, a Bitrise rozwiązuje je niezwykle prosto. Platforma przechowuje certyfikaty i provisioning profiles w zaszyfrowanej formie, automatycznie instaluje je w odpowiednim keychain przed budową i eksportuje podpisany IPA. Step Certificate and Profile Installer pobiera pliki z magazynu Bitrise i konfiguruje Xcode. Obsługiwane są typy certyfikatów Development, AdHoc, AppStore i Enterprise.

Do publikacji w App Store Connect Bitrise udostępnia Steps do przesyłania IPA przez Xcode Archive & Export. Publikacja w Google Play wykorzystuje Gradle Runner z podpisem przez Keystore, po czym APK/AAB jest przesyłany do Google Play Console przez Google Play Deploy Step. Dla Firebase App Distribution wystarczy podać Firebase Token i grupę testerów. Bitrise automatyzuje aktualizację wersji budowy (version number i build number) przed każdą publikacją.

Konfiguracja code signing w Bitrise

Certyfikaty są przesyłane w sekcji Code Signing interfejsu webowego: P12 z kluczem prywatnym, provisioning profile (.mobileprovision), Keystore (.jks/.keystore) dla Androida. Bitrise automatycznie instaluje certyfikaty iOS w keychain przy każdym uruchomieniu Workflow i eksportuje podpisaną aplikację. Dla Androida wystarczy przesłać plik Keystore — Bitrise przekazuje go do Gradle przez zmienne środowiskowe podczas budowy.

Przykład konfiguracji Bitrise dla Flutter

Rozważmy Workflow dla aplikacji Flutter, który buduje i publikuje wersje dla iOS i Android. Bitrise automatycznie wykrywa projekt Flutter i proponuje odpowiednie Steps. Workflow obejmuje instalację Flutter, buforowanie pub-cache, budowanie, testowanie i wdrażanie. Dla budowy iOS wymagane są dodatkowo certyfikaty code signing, które Bitrise ładuje automatycznie.

Podczas budowania aplikacji Flutter Bitrise obsługuje oddzielną konfigurację dla platform. Budowa Android wykonywana jest na Linux runner z Flutter SDK, iOS — na macOS runner. Workflow może obejmować warunkowe Steps: build_android i build_ios, które uruchamiane są tylko na odpowiednich platformach. Dla projektów React Native Bitrise oferuje podobny zestaw Steps z npm/nvm i 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: {}

Niestandardowy Step do wdrażania

Po budowie można dodać Step Firebase App Distribution dla iOS i Android. Step przyjmuje firebase_token, app_id i testers_group. Bitrise podstawia wartości z Secrets — bezpieczne przechowywanie tokenów gwarantuje, że nie trafią one do logów.

- 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 i zarządzanie środowiskiem

Prawidłowe zarządzanie poufnymi danymi to podstawa bezpieczeństwa procesów CI/CD. Bitrise Secrets są szyfrowane i niedostępne do odczytu po zapisaniu. Podczas tworzenia nowej aplikacji Bitrise proponuje importowanie secrets z innego projektu lub ręczne ustawienie. Dla dużych zespołów dostępna jest funkcja Environment Groups — scentralizowane zarządzanie zmiennymi i secrets dla grupy aplikacji.

Bitrise udostępnia wbudowane przechowywanie Secrets dla poufnych danych: klucze API, tokeny Firebase, hasła Keystore, Apple ID. Secrets są ustawiane jako pary klucz-wartość w interfejsie webowym i maskowane w logach budowy. Są dostępne na poziomie aplikacji i na poziomie Workflow. Secrets nie można odczytać po zapisaniu — można je tylko nadpisać.

Environment Variables (bez oznaczenia Secret) są używane do konfiguracji: wersja Xcode, ścieżka do projektu, schemat budowy. Zmienne środowiskowe Bitrise (BITRISE_BUILD_NUMBER, BITRISE_APP_TITLE) dostarczają meta-informacji o budowie. Secrets są szyfrowane podczas przechowywania i odszyfrowywane tylko na runnerze podczas wykonywania Workflow. Do grupowego zarządzania zmiennymi Bitrise obsługuje Environment Groups — zestawy zmiennych, które można zastosować do wielu aplikacji jednocześnie.

Szczególnej uwagi wymaga zarządzanie certyfikatami iOS przez Bitrise. Platforma automatycznie instaluje P12 i provisioning profile w systemowym keychain przed budową. Dla Androida używany jest plik Keystore, który jest przesyłany w sekcji Code Signing. Każdy plik certyfikatu jest przechowywany w zaszyfrowanej formie i odszyfrowywany tylko podczas budowy.

Przykład użycia Secrets

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

Stacki i środowiska Bitrise

Bitrise oferuje różne stacki do budowy — preinstalowane obrazy z narzędziami i SDK. Dostępne są stacki dla Xcode (wersje 14, 15, 16 z iOS SDK 17, 18), dla Androida (z różnymi wersjami SDK i NDK), dla Flutter, React Native i Kotlin Multiplatform. Każdy stack ma opis preinstalowanych narzędzi i wersji.

Wybór stacka wpływa na czas budowy i kompatybilność z projektem. Bitrise regularnie aktualizuje stacki, dodając nowe wersje narzędzi. Można ustalić konkretną wersję stacka w bitrise.yml, aby uniknąć nieoczekiwanych zmian przy aktualizacji platformy. Dla niestandardowych zależności używany jest Script Step, instalujący niezbędne pakiety przed główną budową. Bitrise obsługuje również obrazy Docker dla Linux stacks, co pozwala na użycie niestandardowego środowiska dla budów Android.