Что меняется при доставке мобильного приложения

Если вы годами доставляли веб-приложения, мобильная доставка покажется вам совсем другим миром. В вебе вы собираете, загружаете на сервер — и готово. Пользователи обновляют браузер и видят последнюю версию. Вы контролируете всё: сервер, инфраструктуру, время релиза.

Мобильные приложения так не работают. И различия настолько глубоки, что весь ваш CI/CD-пайплайн нужно менять.

Приложение живёт на чужом устройстве

Первое и самое фундаментальное отличие — где на самом деле выполняется приложение. Мобильное приложение не живёт на сервере, которым вы управляете. Оно живёт на устройстве в чьём-то кармане. Вы не можете заменить файлы на сервере. Вы не можете выкатить хотфикс, который вступит в силу мгновенно.

Каждый раз, когда вы хотите выпустить новую версию, вам нужно пересобрать приложение, подписать его цифровой подписью и отправить в магазин приложений. Затем пользователь должен самостоятельно скачать и установить обновление. Некоторые обновятся сразу. Другие будут игнорировать уведомление неделями. А некоторые не обновятся никогда.

Это меняет то, как вы думаете о доставке. Вы не можете предполагать, что все находятся на последней версии. Вы не можете исправить критическую ошибку и донести исправление до всех пользователей за минуты. Контроль, который у вас был в веб-доставке, исчезает.

Две платформы, две системы сборки

Мобильная доставка означает работу с несколькими системами сборки. Android использует Gradle. iOS использует Xcode. У каждой свои правила относительно версий SDK, зависимостей и форматов вывода. Вы не можете собрать Android-приложение на macOS и доставить его пользователям iOS, и наоборот.

Ваш пайплайн должен обрабатывать два отдельных пути сборки. Они могут выполняться параллельно или последовательно, в зависимости от настройки, но они никогда не одинаковы. Конфигурация сборки для Android живёт в Gradle-файлах. Конфигурация сборки для iOS живёт в файлах проекта Xcode и схемах. Зависимости управляются по-разному. Процесс подписи полностью отличается.

Если вы поддерживаете обе платформы, ваш CI/CD-пайплайн фактически превращается в два пайплайна, которые разделяют некоторую логику тестирования и уведомлений, но расходятся на этапе сборки.

Подпись — не опция

Прежде чем мобильное приложение можно будет установить на устройство пользователя, оно должно быть цифровым подписью. Эта подпись доказывает, что приложение исходит от вас, а не от кого-то, кто выдает себя за вас. Android использует файл keystore. iOS использует сертификаты и provisioning profiles.

Это секретные файлы. Если они утекут, кто-то другой сможет публиковать приложения, которые выглядят как ваши. Если вы их потеряете, вы никогда не сможете выпустить ещё одно обновление для существующего приложения в Play Store или App Store. Восстановления нет. Вам придётся создать новую запись приложения и потерять всех существующих пользователей.

В вашем пайплайне эти файлы должны храниться безопасно. Никогда не зашивайте их в репозиторий. Никогда не коммитьте их в систему контроля версий. Используйте менеджер секретов, зашифрованное хранилище в вашей CI-системе или выделенный сервис подписи. Пайплайн должен иметь доступ к этим файлам только на этапе подписи и нигде больше.

Магазин контролирует время вашего релиза

Вы не можете просто отправить APK или IPA-файл пользователям. Приложение должно пройти через магазин приложений. Google Play Store и Apple App Store имеют свои процессы проверки. Google Play обычно проверяет в течение нескольких часов. Проверка Apple может занять больше времени и часто более строгая.

Это означает, что время между завершением сборки и началом использования новой версии пользователями не под вашим контролем. Третья сторона решает, когда ваше приложение станет доступным. Если они отклонят вашу заявку, вам нужно исправить проблему, пересобрать и отправить снова. Счётчик сбрасывается.

Это также влияет на вашу стратегию отката. В вебе откат означает развёртывание предыдущей версии. На мобильных устройствах вы не можете заставить пользователей вернуться назад. Пользователи, которые уже обновились, останутся на сломанной версии, пока вы не выпустите исправление. И это исправление снова должно пройти проверку.

Постепенные развёртывания становятся необходимыми

Поскольку вы не можете легко откатиться, нужно быть осторожным с тем, как вы выпускаете обновления. И Android, и iOS поддерживают постепенные развёртывания. В Android это называется staged rollout. В iOS — phased release.

Идея проста: сначала вы выпускаете новую версию для небольшого процента пользователей. Может быть, 1% или 5%. Вы отслеживаете отчёты о сбоях, частоту ошибок и отзывы пользователей. Если всё выглядит хорошо, вы расширяете развёртывание до 10%, затем до 25%, затем до 50%, затем до 100%. Если что-то идёт не так, вы приостанавливаете развёртывание. Затронута только та небольшая группа пользователей, которые уже получили обновление.

Это не опция для серьёзной мобильной доставки. Это основной способ снизить риск, когда вы не можете мгновенно откатиться.

Что это значит для вашего пайплайна

Все эти различия в сумме дают CI/CD-пайплайн, который сильно отличается от веб-пайплайна. Ваш мобильный пайплайн должен обрабатывать:

Следующая диаграмма показывает два пути бок о бок, подчёркивая, где мобильная доставка добавляет дополнительные шлюзы.

• Платформозависимые сборки с разными инструментальными цепочками
• Безопасная подпись с секретами, которые никогда не должны утекать
• Загрузка в магазины приложений с автоматической отправкой
• Стратегии постепенного развёртывания, которые можно приостановить или расширить

Вам также нужно думать о тестировании иначе. Эмуляторы и симуляторы могут выявить многие проблемы, но они не идеальны. Некоторые ошибки проявляются только на реальных устройствах с определённым оборудованием, датчиками или сетевыми условиями. Ваш пайплайн должен включать как автоматизированное тестирование на виртуальных устройствах, так и процесс тестирования на физических устройствах перед полным релизом.

Краткий чек-лист для мобильного CI/CD

• Храните ключи подписи и сертификаты в безопасном менеджере секретов, а не в репозитории
• Настройте отдельные задания сборки для Android и iOS с соответствующими инструментальными цепочками
• Автоматизируйте загрузку в Google Play Console и App Store Connect
• Внедрите постепенное развёртывание или поэтапный релиз в вашем пайплайне
• Добавьте сбор и мониторинг отчётов о сбоях, которые запускают оповещения во время постепенного развёртывания
• Тестируйте как на эмуляторах, так и на реальных устройствах перед расширением процента релиза

Вывод

Мобильная доставка — это не веб-доставка с другим шагом сборки. Приложение живёт на устройствах, которые вы не контролируете. Магазин контролирует время вашего релиза. Откат — это не кнопка, которую вы нажимаете. Ваш CI/CD-пайплайн должен учитывать эти реалии с самого начала. Собирайте для платформы, подписывайте безопасно, выпускайте постепенно и мониторьте неусыпно. Это единственный способ доставлять мобильные приложения, не просыпаясь от инцидента на проде, который нельзя исправить до следующего цикла проверки.