Интеграция App Center для распространения бета-версий на Delphi
App Center Distribute позволял передавать тестировщикам сборки Delphi без публикации в магазинах приложений. Разработчик загружал подписанный пакет, создавал группу пользователей и выпускал новую версию через защищённый веб-интерфейс. Такой сценарий особенно удобен для Android и iOS, когда QA-команда, заказчики или партнёры должны регулярно проверять приложение до официального релиза.
В своей кроссплатформенной практике я рассматривал App Center как единый контур доставки сборок, созданных в Delphi и FireMonkey. При этом важно различать runtime-интеграцию сервиса и распространение артефактов: мобильному приложению не требуется встраивать App Center SDK, если пакеты публикуются сервером сборки. Microsoft прекратила работу App Center 31 марта 2025 года, поэтому описанный процесс теперь служит архивной основой для проектирования замены с сохранением накопленных процессов.
Подготовка Delphi-проекта к выпуску
Перед загрузкой пакета требуется подготовить отдельную конфигурацию Release. Она должна использовать те же настройки целевой платформы, что и будущая стабильная версия: идентификатор приложения, иконки, ресурсы, параметры подключения и правила доступа к данным. Это исключает ситуацию, когда бета-сборка работает только благодаря тестовой конфигурации или локальному окружению разработчика.
Для Android применяется подпись release-ключом, а версия задаётся парой значений versionName и versionCode. Имя отражает пользовательскую версию, например 1.4.0, а числовой код должен последовательно увеличиваться. Для iOS версионирование выполняется через CFBundleShortVersionString и CFBundleVersion. Каждый новому пакету нужна уникальная сборка, иначе канал распространения может принять её как дубликат.
Подписанный APK или IPA следует собирать на контролируемой сборочной машине. Android-ключ и сертификаты нельзя сохранять в репозитории или передавать в открытых параметрах команды. Для iOS дополнительно потребуется подходящий provisioning profile, зарегистрированные идентификаторы устройств и согласованный способ распространения между разработчиками и внешними тестировщиками.
Автоматизированная сборка и загрузка
Ручная загрузка быстро теряет воспроизводимость, поэтому сборку лучше связать с локальным скриптом, GitHub Actions, Azure Pipelines или другой CI-системой. Под Windows компиляция Delphi запускается после инициализацииRAD Studio командой вида MSBuild Project.dproj /t:Build /p:Configuration=Release /p:Platform=Android. На macOS и Linux используются соответствующие сборочные сценарии, доступные установленному компилятору.
Готовый артефакт сохраняется в отдельный каталог, после чего проверяется наличие подписи и ожидаемых файлов. Исторический клиент App Center устанавливался через appcenter-cli, а загрузка и выпуск выполнялись одной командой: appcenter distribute release Ravil/DelphiBeta path\to\YourApp.apk --group AndroidBeta --build-version 1.4.0 --build-number 140. Для разных платформ обычно создаются отдельные приложения, чтобы версии и аудитории не смешивались.
В автоматическом процессе токен API хранится в секретах CI, путь к ключу передаётся через переменные окружения, а результат сборки публикуется как неизменяемый артефакт. При сбое загрузки сохраняются журнал команды и идентификатор операции. Такой подход связывает конкретный пакет с исходным коммитом, параметрами компилятора и этапом тестирования.
Группы тестировщиков и выпуск версий
App Center позволял разделить пользователей по группам, например внутренних разработчиков, QA-команду и внешних бета-тестировщиков. Группа определяет, кто получит уведомление и сможет установить выпуск. Оплаченные или расширенные тестировщики получают пакет сразу, а остальные участники могут запросить доступ по ссылке.
| Канал | Платформы и форматы | Доступ пользователей | Контроль версий | Состояние |
|---|---|---|---|---|
| App Center Distribute | Android APK или AAB, iOS IPA | Закрытый портал и приглашения | Группы, примечания, обязательное обновление | Закрыт 31 марта 2025 года |
| Google Play Internal testing | Android AAB или APK | Учётные записи Google из списка | Треки, статусы проверки, отзывы | Доступен |
| TestFlight | iOS IPA через App Store Connect | Приложение TestFlight и код регистрации | Срок действия сборки, анкеты, отзывы | Доступен |
| Закрытое хранилище пакетов | APK, IPA, MSI, DMG, AppImage и другие форматы | Учётная запись или подписанная ссылка | Собственный журнал версий | Требует сопровождения |
Разделение каналов помогает согласовать разные модели доступа. Google Play Internal testing удобен для постоянной QA-команды, а TestFlight лучше соответствует правилам распространения iOS. Собственное хранилище остаётся гибким вариантом для Windows, macOS и Linux, хотя разработчику приходится самостоятельно организовывать аутентификацию, сроки жизни ссылок и уведомления.
Загруженный пакет можно сначала сохранить без рассылки, проверить метаданные и только затем отправить выбранной группе. Такой двухэтапный процесс снижает риск преждевременной публикации. В примечаниях к выпуску полезно указывать основные изменения, известные дефекты и области, требующие повторной проверки.
Сравнение каналов бета-распространения
Для Android переход от App Center к Google Play обычно сохраняет привычный сценарий установки по ссылке, но добавляет проверку версии, управление тестовыми треками и правила аккаунта. Разработчик получает больше сведений о состоянии публикации, однако состав участников и параметры распространения становятся частью консоли Google Play.
TestFlight использует другую цепочку: подписанный пакет загружается через App Store Connect, после чего становится доступен в приложении TestFlight. Каждая сборка имеет ограниченный срок действия, а замечания проходят модерацию Apple. Для внешнего тестирования потребуется подтверждение аккаунта, зато установка на iOS выполняется без App Center.
Для настольных платформ App Center никогда не заменял полноценный менеджер обновлений. Delphi-приложения для Windows, macOS и Linux обычно распространяются через собственные серверы, CDN или закрытые объектные хранилища. Пакет MSI, DMG, AppImage или архив дополняется контрольными суммами, инструкцией обновления и политикой версий.
Безопасность и сопровождение релизов
Безопасность начинается с разделения сборочных ролей. Один CI-сервис компилирует проект, другой управляет секретами, а третий отвечает за публикацию. Токен распространения должен иметь минимальные права, а журналы команд — исключать значения переменных, приватные ключи и персональные данные участников.
Для каждого релиза полезно сохранять манифест с версией, сборкой, датой, хешем пакета, целевой платформой и перечнем тестовых сценариев. Такой журнал можно вести в базе данных проекта или репозитории. Он упрощает откат, позволяет определить источник ошибки и показывает, какая конфигурация действительно дошла до тестировщиков.
Современная замена App Center строится по тем же принципам: подпись, автоматическая сборка, закрытый доступ, проверка версии и обратная связь. Firebase App Distribution подходит для Android-пакетов, TestFlight — для iOS, а защищённое хранилище обслуживает настольные версии. Сохранение единого процесса важнее конкретного названия сервиса: именно оно обеспечивает повторяемую доставку бета-версий между Almaty и командами в других странах.