Процесс релиза iOS-приложения
Вопрос
Расскажите, как устроен релиз в вашей команде: от ветки до App Store.
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Релизная ветка или тег, заморозка фич, регресс
CI собирает и подписывает (fastlane, Xcode Cloud), грузит в TestFlight
Внутреннее и внешнее тестирование, чек-лист
Ревью с демо-доступом и заметками
Поэтапный релиз, мониторинг крэшей и метрик, пауза при проблемах
Фича-флаги для отключения без нового релиза
Что могут спросить следом
- Что вы делаете, если в релизе критический баг, а ревью занимает время?
- Как часто вы релизитесь и почему?
Разбор
У нас релизный поезд раз в одну-две недели. В день отсечки создаётся релизная ветка, фичи в неё больше не попадают, только фиксы. CI собирает архив, подписывает (ключи и профили управляются централизованно) и загружает в TestFlight, туда же уходит dSYM для крэш-аналитики. QA проходит регресс по чек-листу, внутренние тестеры пользуются сборкой. Затем версия уходит на ревью с демо-аккаунтом. После одобрения включаем поэтапный релиз и смотрим на crash-free, отзывы и бизнес-метрики. Если что-то пошло не так, ставим раскатку на паузу и выключаем проблемную фичу флагом. Критичный фикс отправляем с запросом ускоренного ревью.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Предыдущий вопрос
Принудительное обновление мобильного приложения
Следующий вопрос
Swift Package Manager
Термины по теме
Ещё по теме «Сборка и публикация в App Store»
- Удаление аккаунта и App Review
- Зачем нужен dSYM
- Entitlements и capabilities
- Частые причины отклонения на App Review
- Подпись iOS-приложения
- Оплата цифровых товаров в iOS-приложении
- Задача на Swift: сравнение версий для принудительного обновления
- Бинарный фреймворк и стабильность модуля