Налаштування AppCenter для CI/CD мобільного застосунку під ключ

При розробці мобільного застосунку на SwiftUI з інтеграцією Firebase та push-сповіщеннями ручна збірка кожної версії для iOS та Android забирає до 4 годин на день. Через два тижні після старту проєкту команда витрачає 30% часу на повторювані операції: підпис коду, конфігурацію середовища, завантаження в TestFlight. Ми налаштовуємо CI/CD в Microsoft AppCenter, щоб кожна збірка проходила автоматично: по push у Git, з прогоном UI-тестів на реальних пристроях і відправкою білда тестувальникам. Весь процес займає 2–5 днів, а не тижні. За цей час ви отримуєте надійний конвеєр, який скорочує час релізу на 70% і знижує витрати на інфраструктуру тестування до 50%.

Чому AppCenter — зручний вибір для CI/CD?

AppCenter вирішує три ключові завдання: збірка, тестування на реальних пристроях (Device Farm) та дистрибуція. На відміну від Jenkins або GitLab CI, вам не потрібно керувати інфраструктурою — сервіс надає віртуальні машини macOS та Windows, а також пристрої iOS/Android. Згідно з документацією Microsoft, AppCenter підтримує всі популярні фреймворки: SwiftUI, Jetpack Compose, Flutter та React Native. Єдине обмеження — складні матричні збірки та кастомні образи, але ми вирішуємо це комбінацією із зовнішнім CI (наприклад, GitHub Actions).

Як налаштувати збірку через YAML-конфігурацію?

AppCenter підтримує appcenter.yml — це найбільш гнучкий спосіб описати пайплайн. Приклад для iOS-застосунку з ручним підписом:

---
trigger:
  branches:
    include:
      - main
      - release/*
pool:
  vmImage: macos-latest
steps:
  - task: InstallAppleCertificate@2
    inputs:
      certSecureFile: distribution.p12
      certPwd: $(P12_PASSWORD)
  - task: InstallAppleProvisioningProfile@1
    inputs:
      provisioningProfileLocation: secureFiles
      provProfileSecureFile: MyApp_AppStore.mobileprovision
  - script: |
      cd ios && pod install --repo-update
    displayName: 'Install CocoaPods'
  - task: Xcode@5
    inputs:
      actions: 'build'
      scheme: 'MyApp'
      xcWorkspacePath: 'ios/MyApp.xcworkspace'
      exportPath: '$(Build.ArtifactStagingDirectory)'
      exportOptions: 'plist'
      exportOptionsPlist: 'ios/ExportOptions.plist'
      signingOption: 'manual'
      signingIdentity: '$(APPLE_CERTIFICATE_SIGNING_IDENTITY)'
      provisioningProfileUuid: '$(APPLE_PROV_PROFILE_UUID)'

Якщо YAML недоступний, використовуємо appcenter-post-build.sh — він викликається після успішної збірки. Наприклад, для відправки білда в групу QA:

#!/usr/bin/env bash
appcenter distribute release \
  --app "$APPCENTER_APP_ID" \
  --file "$APPCENTER_OUTPUT_DIRECTORY/MyApp.ipa" \
  --group "QA Team" \
  --release-notes "Build $APPCENTER_BUILD_ID"

curl -X POST "$SLACK_WEBHOOK_URL" \
  -H 'Content-type: application/json' \
  --data "{\"text\":\"New build $APPCENTER_BUILD_ID is available\"}"

Змінні APPCENTER_* — вбудовані середовища, доступні на етапі збірки.

Як захистити секрети та керувати середовищем?

У Build Configuration → Environment Variables додаються ключі. Чутливі значення позначаються як «Secret» — вони шифруються і не виводяться в логи. Стандартний набір:

AppCenter гарантує, що секрети не потраплять до логів збірки.

Як тестувати на реальних пристроях?

Device Farm запускає XCUITest та Espresso на фізичних iPhone та Android-смартфонах. Команда завантаження тестів:

appcenter test run xcuitest \
 --app "MyOrg/MyApp-iOS" \
 --devices "MyOrg/top-ios-devices" \
 --test-series "main" \
 --locale "uk_UA" \
 --build-dir DerivedData/Build/Products/Debug-iphoneos

Пристрої вибираються в UI — можна задати пріоритетні моделі та версії ОС. Це швидше, ніж налаштовувати власну ферму: економія до 30% бюджету на тестування.

Які проблеми вирішує налаштування AppCenter?

Перша проблема — ручний підпис коду для iOS. Кожний реліз потребує оновлення provisioning profiles та сертифікатів. Ми автоматизуємо цей процес через InstallAppleCertificate та InstallAppleProvisioningProfile, що виключає помилки при збірці.

Друга проблема — відсутність тестів на реальних пристроях. Симулятор не завжди відтворює баги, пов'язані з пам'яттю або мережею. Device Farm запускає тести на 5+ фізичних девайсах, що збільшує покриття на 40%.

Третя проблема — затримки в дистрибуції. Ручна відправка білда тестувальникам через TestFlight займає до години. Post-build скрипт відправляє IPA/APK безпосередньо в групи AppCenter, сповіщаючи команду в Slack за хвилину.

Структура проєкту в AppCenter

Для кожного застосунку створюється окремий «app» всередині організації. Типова ієрархія:

MyCompany (Organization)
├── MyApp-iOS (App)
│   ├── Build (CI)
│   ├── Test (Device Farm)
│   ├── Distribute
│   └── Diagnostics (Crashes)
└── MyApp-Android (App)
    ├── Build (CI)
    ├── Distribute
    └── Diagnostics

Така структура спрощує управління доступами — тестувальники бачать лише свої застосунки.

Обмеження AppCenter CI та як їх обійти

AppCenter не підтримує матричні збірки (декілька конфігурацій в одній роботі) та кастомні Docker-образи для Android. У таких випадках ми залишаємо в AppCenter тільки дистрибуцію та крашлітику, а складний пайплайн реалізуємо через GitHub Actions. Ви отримуєте краще з обох світів: гнучкість зовнішнього CI та зручність AppCenter для доставки тестувальникам.

Що входить у налаштування CI/CD?

Після завершення робіт ви отримуєте:

• Робочий пайплайн в AppCenter з тригерами на main/release гілки
• Налаштований підпис для iOS (сертифікати та provisioning profiles)
• UI-тести на Device Farm (до 5 пристроїв кожної платформи)
• Автоматичну дистрибуцію в групи тестувальників (TestFlight/Google Play за запитом)
• Документацію щодо процесу та контакти підтримки

Терміни та вартість

Орієнтовний термін — від 2 до 5 днів залежно від складності проєкту. Вартість розраховується індивідуально після оцінки. Наша команда має 5+ років досвіду в мобільній розробці та реалізувала CI/CD для 20+ проєктів. Замовте налаштування — зв'яжіться з нами для отримання консультації та оцінки вашого проєкту. Отримайте консультацію з налаштування CI/CD вже сьогодні.