Сборка и поставка нативных мобильных приложений¶
Требования применяются к release-сборкам iOS и Android. Уровни обязательности
определены в корневом README.md.
MOB-BUILD-001. Зафиксированная среда сборки¶
Уровень: MUST
Применяется к: локальной среде и CI-сборке
Для каждой поддерживаемой платформы CI должен использовать зафиксированную среду: macOS Runner с зафиксированной версией Xcode для iOS и зафиксированный Linux container для Android. Локальная среда должна использовать совместимые зафиксированные версии toolchain. Применимые версии Java, Gradle, Android SDK, build tools и Xcode должны проверяться до сборки.
Обоснование¶
Сборка мобильного binary зависит от платформенного toolchain.
Проверка¶
- вывод и сравнение версий в CI;
- сборка на чистом runner;
- тест несовпадающей версии.
Исключения¶
Не допускаются для release pipeline.
MOB-BUILD-002. Детерминированная сборка и идентификация¶
Уровень: MUST
Применяется к: каждому release artifact
Artifact должен однозначно связываться с полным commit SHA, pipeline, версией приложения и монотонным build number. Один build number не должен повторно обозначать другой binary. Подписываемый artifact должен быть тем же artifact, который прошёл проверки.
Обоснование¶
Идентификация связывает установленное приложение с кодом и проверками.
Проверка¶
- чтение metadata из IPA/AAB/APK;
- сопоставление с commit и pipeline;
- checksum до и после этапов проверки.
Исключения¶
Криптографическая подпись изменяет контейнер допустимым системным способом, но не должна пересобирать приложение.
MOB-BUILD-003. Управление signing credentials¶
Уровень: MUST
Применяется к: сертификатам, provisioning profiles и signing keys
Signing credentials должны храниться вне Git и runner image, выдаваться только защищённой release job и не выводиться в лог. Android upload key и iOS сертификаты должны иметь владельца, backup, ротацию и процедуру отзыва.
Обоснование¶
Компрометация ключа позволяет выпускать поддельные обновления.
Проверка¶
- secret scanning;
- review protected variables и runner access;
- rehearsal ротации и восстановления.
Исключения¶
Локальный debug key не должен использоваться для release.
MOB-BUILD-004. Каналы предварительной поставки¶
Уровень: MUST
Применяется к: предрелизной проверке
Для iOS release candidate должен поставляться через TestFlight. Для Android должен использоваться testing-канал каждого магазина, в который планируется production-публикация, например Google Play Internal Testing или RuStore Testing. Предрелизный binary должен совпадать с кандидатом production по коду, зависимостям и release-конфигурации.
Обоснование¶
Store-managed testing проверяет реальную установку, подпись и обновление.
Проверка¶
- сопоставление version/build и checksum;
- установка и upgrade из канала testing;
- проверка release configuration.
Исключения¶
Ad-hoc debug distribution не подтверждает готовность release.
MOB-BUILD-005. Production-каналы и продвижение¶
Уровень: MUST
Применяется к: публикации production
iOS должна публиковаться через Apple App Store. Android должен публиковаться
через заранее объявленные проектом production-магазины, для которых тот же
release candidate прошёл testing-канал по MOB-BUILD-004. В production должен
продвигаться проверенный release candidate без пересборки. Store metadata,
privacy declarations и release notes должны соответствовать binary.
Обоснование¶
Продвижение одного кандидата исключает расхождение тестовой и production-сборки.
Проверка¶
- сравнение artifact ID между testing и production;
- review store declarations;
- установка опубликованной версии.
Исключения¶
Экстренный hotfix проходит тот же pipeline и может иметь сокращённое окно review.
MOB-BUILD-006. Управляемое поэтапное распространение¶
Уровень: MUST
Применяется к: production release
Проект должен использовать staged/phased rollout, если магазин его поддерживает. Численные этапы, критерии продвижения и остановки должны учитывать crash-free sessions, ошибки, ANR на Android и пользовательские SLI. Отсутствие телеметрии должно останавливать продвижение.
Обоснование¶
Поэтапный rollout ограничивает число затронутых устройств.
Проверка¶
- review rollout policy;
- тест остановки по порогу;
- сверка метрик по версии.
Исключения¶
Для магазина без staged rollout проект должен определить ручной план ограничения риска и остановки распространения; отдельный ADR не требуется.
MOB-BUILD-007. Контроль размера приложения¶
Уровень: SHOULD
Применяется к: release artifact и store download
CI следует измерять compressed download size и установленный размер отдельно для поддерживаемых platform/architecture variants. Проекту следует определить численный бюджет либо максимально допустимую регрессию относительно зафиксированного baseline.
Превышение следует блокировать до review вклада dependencies, native binaries и assets. Сравнение universal artifact без размера фактически доставляемого variant не следует считать достаточным.
Обоснование¶
Рост размера ухудшает установку и обновление и часто появляется незаметно через транзитивную зависимость или дублированный asset.
Проверка¶
- машинно-читаемый отчёт размеров по variants;
- controlled добавление крупного asset;
- сравнение CI с metadata store candidate.
Исключения¶
Превышение MAY быть принято для необходимой возможности с зафиксированным вкладом, причиной и новым baseline.