Настройка CI/CD для iOS-приложения через Bitrise

Настройка CI/CD для iOS-приложения через Bitrise

Bitrise — облачный CI/CD, заточенный под мобильную разработку. Его главное отличие от GitHub Actions или GitLab CI: все шаги (Steps) — это готовые блоки из Workflow Editor с UI-настройкой, и большинство мобильных сценариев настраивается без написания yaml «с нуля». Для команд без DevOps-эксперта — это снижает порог входа.

Workflow Editor и структура конфигурации

Bitrise хранит конфигурацию в bitrise.yml в корне репозитория. Редактировать можно и через UI, и напрямую в yaml. Базовый workflow для iOS:

workflows:
  primary:
    steps:
    - activate-ssh-key: {}
    - git-clone: {}
    - certificate-and-profile-installer: {}
    - cocoapods-install:
        inputs:
        - is_cache_disabled: "false"
    - xcode-test:
        inputs:
        - scheme: MyApp
        - simulator_device: iPhone 15
    - xcode-archive:
        inputs:
        - scheme: MyApp
        - distribution_method: ad-hoc
    - deploy-to-bitrise-io: {}
    - firebase-app-distribution:
        inputs:
        - app: $FIREBASE_APP_ID
        - groups: qa-team

certificate-and-profile-installer — Bitrise-специфичный Step, который скачивает сертификаты из Bitrise Code Signing вкладки. Туда загружаются .p12 и .mobileprovision файлы через UI или API. Это проще чем fastlane match, но означает хранение сертификатов на серверах Bitrise.

Code Signing без fastlane match

В Bitrise есть встроенный Code Signing Manager. Загружаем через Web UI:

1. Distribution certificate (.p12 + passphrase)
2. Provisioning profile (.mobileprovision)

xcode-archive Step автоматически использует загруженные сертификаты через BITRISE_CERTIFICATE_URL и BITRISE_CERTIFICATE_PASSPHRASE environment-переменные. Xcode Automatic Signing при этом отключаем в xcode-archive:

- xcode-archive:
    inputs:
    - automatic_code_signing: api-key  # или certificate

api-key режим использует App Store Connect API Key (лучший вариант — не истекает, в отличие от сертификата).

Параллельные workflow и triggers

Bitrise поддерживает несколько workflow с разными триггерами:

trigger_map:
- push_branch: main
  workflow: deploy
- push_branch: "feature/*"
  workflow: test-only
- pull_request_target_branch: main
  workflow: pr-check

test-only workflow запускает только тесты без архивации — экономит ~10 минут на каждый push в feature-ветку.

Кэширование

Bitrise использует свой механизм кэша через Steps save-cache / restore-cache:

- restore-cache:
    inputs:
    - key: "cocoapods-{{ checksum \"Podfile.lock\" }}"
    - path: ./Pods
- cocoapods-install: {}
- save-cache:
    inputs:
    - key: "cocoapods-{{ checksum \"Podfile.lock\" }}"
    - path: ./Pods

SPM-зависимости кэшируются через ~/Library/Developer/Xcode/DerivedData — можно добавить в path аналогично.

Ограничения по сравнению с self-hosted

Bitrise — только облако. Раннеры: Xcode 15 (macOS 13), Xcode 16 (macOS 14) и т.д. — выбираются в machine type. Самый быстрый — M2 Elite XL (~4 минуты на архивацию среднего проекта). Стоимость зависит от плана; при интенсивной разработке на команду из 5+ человек облачные минуты заканчиваются быстро.

Если нужна сборка каждого коммита + ночные UI-тесты на реальных устройствах — Bitrise + Device Testing (Firebase Test Lab или собственный device farm).

Типичные проблемы при настройке

• Несоответствие bundle ID в provisioning profile и PRODUCT_BUNDLE_IDENTIFIER в xcconfig — xcode-archive падает с No profile for... signed for running on device
• CocoaPods-версия на Bitrise-стеке отличается от локальной — добавляем gem install cocoapods --version X.X.X в Script Step
• Не установлен BITRISE_SCHEME — xcode-test использует первую доступную схему, что может быть не той

Сроки

Базовая настройка Bitrise (test + archive + TestFlight): 2–4 дня. Полная конфигурация с параллельными workflows, Device Testing, кэшированием, Slack/Jira-интеграцией: 1–1.5 недели. Стоимость рассчитывается индивидуально.