Как раскатывал тестовые сборки на iOS

Развертывание тестовых сборок на iOS: полный цикл от сборки до установки на устройство

Развертывание тестовых сборок (раскатка) на iOS — это критически важный процесс в QA, который требует понимания всей цепочки: от настройки проекта в Xcode до установки сборки на физические устройства и симуляторы. Вот детальный разбор этого процесса.

Основные подходы и инструменты

В зависимости от целей тестирования и состава команды, я использовал несколько ключевых методов:

1. Прямая установка через Xcode: Самый базовый способ для разработки и отладки.

    *   Подключаю устройство по USB, выбираю его как target в Xcode.
    *   Убеждаюсь, что **iOS Developer Certificate** и **Provisioning Profile** (с включенным UDID устройства) корректно настроены.
    *   Нажимаю `Cmd + R` для сборки и запуска.

```swift
// Пример проверки в коде, доступна ли фича только в debug-конфигурации
#if DEBUG
    print("Отладочная сборка: включены логи и тестовый сервер")
    let apiBaseURL = "https://test.api.example.com"
#else
    let apiBaseURL = "https://api.example.com"
#endif
```

2. Создание .ipa файла для Ad-Hoc дистрибуции: Основной способ для установки на устройства команды (QA, PM, дизайнеры).

    *   В Xcode выбираю схему сборки (`Edit Scheme...`) -> `Release` (или отдельную `AdHoc` конфигурацию).
    *   В настройках проекта (`Signing & Capabilities`) выбираю **Ad-Hoc provisioning profile**.
    *   Архивирую проект через `Product` -> `Archive`.
    *   В окне `Organizer` выбираю `Distribute App` -> `Ad-Hoc Distribution`.
    *   Экспортирую `.ipa` файл и **manifest.plist**.

1. Использование сервисов для OTA-дистрибуции (Over-The-Air): Наиболее эффективный способ для команды.

    *   **Apple TestFlight (через App Store Connect):** Официальный инструмент для бета-тестирования внешними и внутренними тестерами.
        *   Загружаю архив в **App Store Connect**.
        *   Добавляю внутренних тестеров (члены команды) или отправляю сборку на внешнее бета-тестирование (требует ревью Apple, но не такой строгий, как для продакшена).
        *   Тестеры устанавливают сборку через приложение **TestFlight**.
    *   **Сторонние сервисы (Firebase App Distribution, Microsoft App Center, diawi.com):**
        *   Загружаю `.ipa` файл на платформу.
        *   Сервис генерирует уникальную ссылку для установки и QR-код.
        *   Добавляю UDID устройств тестировщиков в provisioning profile (для Ad-Hoc) или использую In-House профиль (для корпоративного аккаунта).
        *   Рассылаю ссылку команде. Установка происходит через **Safari** по схеме `itms-services://`.

    ```html
    <!-- Пример манифеста для OTA-установки -->
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
        <key>items</key>
        <array>
            <dict>
                <key>assets</key>
                <array>
                    <dict>
                        <key>kind</key>
                        <string>software-package</string>
                        <key>url</key>
                        <string>https://your-distribution-service.com/app.ipa</string>
                    </dict>
                </array>
                <key>metadata</key>
                <dict>
                    <key>bundle-identifier</key>
                    <string>com.yourcompany.appname</string>
                    <key>bundle-version</key>
                    <string>1.2.3</string>
                    <key>kind</key>
                    <string>software</string>
                    <key>title</key>
                    <string>Your App Name</string>
                </dict>
            </dict>
        </array>
    </dict>
    </plist>
    ```

Ключевые шаги и лучшие практики в процессе QA

1. Подготовка и проверка:

    *   **Версионирование:** Убеждаюсь, что версия сборки (`CFBundleShortVersionString`) и build номер (`CFBundleVersion`) в `Info.plist` инкрементированы. Это критически важно для отслеживания, какая сборка установлена на устройстве.
    *   **Конфигурации:** Использую разные конфигурации Xcode (`Debug`, `Release`, `AdHoc`, `Staging`) для управления настройками (например, URL API, ключи аналитики, уровень логирования).
    *   **Регистрация устройств:** Своевременно добавляю UDID новых устройств тестировщиков в **Apple Developer Portal** и обновляю provisioning profiles.

1. Автоматизация (CI/CD):

    *   Настраиваю сценарии в **Jenkins**, **GitLab CI** или **Fastlane** для автоматической сборки, подписи и загрузки на TestFlight или сторонний сервис при пуше в определенную ветку (например, `develop` или `release/*`).
    *   Это минимизирует ручные ошибки и ускоряет процесс.

```ruby
# Пример простого скрипта Fastlane для создания Ad-Hoc сборки и загрузки в Firebase
lane :deploy_to_qa do
  increment_build_number
  gym(scheme: "YourApp-AdHoc", export_method: "ad-hoc")
  firebase_app_distribution(
    app: "1:1234567890:ios:abcdef1234567890",
    groups: "qa-team, product-managers",
    release_notes: "Automated build from branch #{git_branch}"
  )
end
```

3. Коммуникация и документация:

    *   Всегда сопровождаю раскатку новой сборки **релизными нотами** (changelog), которые включают: номер версии, список изменений (фичи, багфиксы), известные issues, области для особого внимания при тестировании.
    *   Использую Slack, Teams или email для уведомления команды с четким указанием, что тестировать и куда сообщать о багах (например, ссылка на Jira или другой трекер).

1. Установка и валидация на устройстве:

    *   После получения ссылки или приглашения в TestFlight проверяю:
        *   Устанавливается ли приложение без ошибок.
        *   Совпадает ли отображаемая версия с ожидаемой.
        *   Запускается ли приложение и проходит ли основные сценарии (smoke test).

Типичные проблемы и их решения

• Ошибка установки «Unable to Install App»: Чаще всего связана с проблемами provisioning profile. Решение: перепроверить, включен ли UDID устройства в профиль, и перегенерировать профиль при необходимости.
• Истек срок действия сертификата: Нужно обновить сертификат в Developer Portal и перевыпустить provisioning profiles.
• Ограничение числа устройств для Ad-Hoc: Аккаунт разработчика Apple позволяет регистрировать до 100 устройств в год. Важно вести учет и очищать список от неиспользуемых устройств.
• Разные конфигурации для разных сервисов: Например, сборка для TestFlight должна быть сконфигурирована иначе, чем для внутреннего Ad-Hoc, чтобы избежать конфликтов с App Store.

Итог: Успешная раскатка тестовых сборок на iOS — это хорошо отлаженный процесс, сочетающий правильную настройку кодовой подписи (Code Signing), выбор оптимального метода дистрибуции, автоматизацию там, где это возможно, и четкую коммуникацию внутри команды. Это обеспечивает стабильный и предсказуемый поток сборок для QA, что напрямую влияет на скорость и качество тестирования.