Релизный день в разработке приложений: суть, этапы и подготовка
Релизный день (release day) — запланированная дата выхода новой версии мобильного приложения, включающая подготовку билда, ревью стором, staged rollout и мониторинг. Для iOS приложений процесс начинается с загрузки билда в App Store Connect за 24-48 часов до planned release date из-за обязательного ревью Apple. Для Android — сборка и загрузка в Google Play Console, где процесс ревью обычно занимает 1-4 часа. По данным Apple Developer Guidelines (2025), 90% билдов проходят ревью за 24 часа. Staged rollout позволяет минимизировать impact при обнаружении ошибок после публикации.
Главное
- Release day — комплекс мероприятий от сборки билда до мониторинга после rollout
- Staged rollout — постепенное раскатывание: 1%, 10%, 50%, 100%
- Smoke testing — финальная проверка билда перед отправкой в стор
- Rollback plan — заранее подготовленный сценарий отката при критических ошибках
- Release retrospective — анализ процесса после завершения rollout на 100%
Что такое релизный день и как к нему готовиться
Релизный день — это не просто момент нажатия кнопки Publish. Это скоординированный процесс, в котором участвуют разработчики, QA, девопсы, продакт-менеджеры и иногда поддержка. Подготовка начинается за 2-3 недели до дня релиза: согласование scope, code freeze, регрессионное тестирование, подготовка release notes и маркетинговых материалов. Чем тщательнее подготовка, тем спокойнее проходит сам релизный день.
Checklist подготовки к релизному дню включает: финальный QA прогон (regression + smoke suite) на релизном билде; проверку метаданных в сторах (название, описание, скриншоты, keywords); согласование staged rollout percentage с продакт-менеджером; подготовку rollback плана (какой тег передеплоить, сколько времени займёт); оповещение команды и смежных сервисов о предстоящем релизе. Release checklist должен быть автоматизирован через CI/CD — например, в виде GitHub Actions workflow, который проверяет все пункты перед созданием релизного тега.
Важный элемент подготовки — blackout period (период, когда деплои на продакшен запрещены). Обычно blackout вводится за 48 часов до релизного дня и снимается через 24 часа после успешного rollout на 100%. Это предотвращает случайные деплои, которые могут помешать релизу. Change freeze в период blackout распространяется на все сервисы, связанные с релизом.
Подготовка билда: код-фриз, тегирование и сборка
За 24-48 часов до релизного дня вводится code freeze — полная остановка изменений в коде. Разработчики переключаются на подготовку документации и release notes. DevOps собирает релизный билд из зафиксированного тега (например, v2.6.0-rc1). Билд проходит полный regression suite (автоматические + ручные тесты). Если найдены critical bugs — они исправляются до code freeze или релиз переносится. Release candidate (RC) — билд, прошедший QA и готовый к отправке в стор.
Тегирование в Git: создаётся аннотированный тег (git tag -a v2.6.0 -m "Release v2.6.0"). CI/CD пайплайн собирает AAB (Android App Bundle) для Google Play и IPA (iOS App Store Package) для Apple App Store. К билду прилагается: файл с контрольными суммами (SHA256), changelog и список известных issues (known issues). Reproducible builds — ideal практика, при которой повторная сборка из того же тега даёт бинарно идентичный результат.
bash
# Release pipeline — tag creation and build
# Assumes code freeze is already active
# Create release branch from develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: branch protection rules block new PRs
# Run regression suite in CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Create release tag after successful QA
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Build release binary via CI/CD
# fastlane build_release produces AAB + universal APK
fastlane build_releaseВажно: version bump (обновление version code и version name) делается до code freeze. После code freeze версия не меняется. Для Android: versionCode — монотонно возрастающее целое; versionName — семантическая версия (2.6.0). Для iOS: CFBundleVersion (build number) и CFBundleShortVersionString (semantic version). Versioning должно быть автоматизировано в gradle/xcconfig.
Загрузка в стор и прохождение ревью
Для iOS: билд загружается через Xcode, Transporter или fastlane в App Store Connect. После загрузки билд проходит автоматическую проверку Apple (processing), затем отправляется на ручное ревью. Среднее время ревью — 24 часа, но может варьироваться от 1 часа до 7 дней в зависимости от загрузки ревьюеров Apple и compliance-требований. Expedited review — запрос ускоренного ревью для critical bug fixes (доступен не чаще раза в месяц, не гарантирован).
Для Android: билд загружается через Google Play Console. Google использует комбинированный подход: автоматическое тестирование (accessibility, malware, policy compliance) + выборочное ручное ревью. Среднее время ревью — 1-4 часа. Internal test track и Closed track позволяют провести финальное тестирование до публикации в Production track. Рекомендуется: 1-2 дня на Internal test → 1 день на Closed beta → постепенный Production rollout.
Для обеих платформ критически важно проверить метаданные до загрузки билда: название приложения, описание (short + full), скриншоты для каждого supported device (iPhone 6.5", 5.5", iPad, Android phone, tablet), keywords (iOS) или store listing experiments (Android). Ошибка в метаданных может задержать ревью на дополнительные сутки. App metadata должна быть локально на всех supported languages.
Staged rollout: как раскатывать релиз без риска
Staged rollout (gradual rollout, staged deployment) — стратегия, при которой новая версия становится доступной пользователям не сразу, а поэтапно. Типичная схема для mature команды: 1% пользователей (первые 2-4 часа) → 10% (24 часа) → 25% (24 часа) → 50% (24 часа) → 100%. Каждый этап включает мониторинг метрик и проверку отсутствия критических ошибок. Staged rollout — основной инструмент минимизации риска при релизах.
Google Play Console предоставляет встроенный staged rollout: можно указать процент пользователей и запланировать постепенное увеличение. Для iOS App Store Connect такой встроенной возможности нет — staged rollout реализуется через Phased Release (автоматическое увеличение охвата в течение 7 дней с возможностью приостановки) или через server-side feature flags с геораспределением. Phased release в App Store Connect даёт возможность Pause Release при обнаружении проблем.
Ключевые метрики для перехода к следующему этапу: crash-free rate (≥99.9% для нового релиза), ANR rate (Android, ≤0.1%), error rate на backend API (≤0.5% 5xx), user ratings (не ниже предыдущей версии), apdex score (≥0.94). Если любая метрика выходит за порог — rollout приостанавливается до выяснения причин. Go/no-go gate на каждом этапе — responsibility release manager или on-call инженера.
Мониторинг после релиза: на что смотреть в первые часы
Первые 4 часа после релиза — самое критическое время. Команда мониторит crash rate (Sentry, Firebase Crashlytics, App Center), error rate 5xx на backend, custom events (успешные платежи, логины, регистрации), user ratings в App Store и Google Play, social media упоминания (Twitter, Reddit). Dashboard мониторинга должен быть подготовлен заранее и доступен на большом экране в офисе или в выделенном Slack channel. Release dashboard — single pane of glass для всех метрик релиза.
Особое внимание — regression метрикам: сравнение crash rate с предыдущей версией за аналогичный период. Если crash rate вырос более чем на 0.1% — это red flag, требующий немедленного анализа. Также важно сравнить median и p95 latency ключевых API-эндпоинтов: даже без крашей, замедление времени ответа на 200ms может сигнализировать о проблеме. Metric comparison (baseline vs current) автоматизируется в Datadog или Grafana.
User feedback — не менее важен, чем численные метрики. В первые часы после релиза пользователи активно оставляют отзывы в сторах и пишут в support. Баги, не пойманные тестами, быстро всплывают в отзывах. Team lead или выделенный QA инженер мониторит отзывы каждые 30 минут в первые 4 часа и классифицирует: false positive, known issue (уже в списке known issues), new bug. New bugs P0/P1 — триггер для приостановки rollout.
Rollback: когда и как откатывать релиз
Rollback — откат до предыдущей стабильной версии при обнаружении критических проблем. Решение о rollback принимается release manager совместно с tech lead, если: crash-free rate нового релиза падает ниже 99%, обнаружена утечка данных, критический функционал (платежи, авторизация) не работает для >5% пользователей, или сторилитейт (App Store Review) отклонил билд после публикации. Rollback trigger должен быть определён до релиза, чтобы решение принималось на основе фактов, а не эмоций.
Для Android: rollback в Google Play Console — остановка staged rollout и переключение на предыдущую версию. Если текущий билд уже на 100% пользователей — публикация предыдущей версии как нового релиза. Для iOS: через App Store Connect — Phased Release → Pause Release → выпуск новой версии с исправлением (App Store не позволяет откатить до предыдущей версии). iOS rollback сложнее: разработчику нужно собрать новый билд с revert-коммитами и пройти ревью заново.
После rollback команда переходит в режим инцидента: root cause analysis, hotfix или следующий релиз с исправлением, post-mortem. Rollback — не failure, а штатная процедура. Команды, которые никогда не делали rollback, скорее всего, не замечают проблему, а не выпускают безбажные релизы. Rollback rate — один из DORA metrics: высокопроизводительные команды делают rollback <10% релизов и восстанавливаются за <1 час.
Часто задаваемые вопросы
В какой день лучше делать релиз мобильного приложения?
Лучший день — вторник, среда или четверг. Понедельник — высокий трафик от выходных, пятница — риск входить в выходные с проблемным релизом. Избегай пятницы: если после деплоя обнаружится проблема, команда будет фиксить её в выходные или ждать понедельника.
Что делать, если App Store Review отклонил билд?
Прочитать причину отклонения в Resolution Center, исправить и перезагрузить билд. Частые причины: неработающие ссылки, незаполненные поля, контент без подписки (если требуется), устаревшие скриншоты. App Review rejection задерживает релиз на 24-48 часов, поэтому первая загрузка билда должна быть за 3-5 дней до planned release date.
Какой процент staged rollout оптимален для начала?
Для крупных релизов (major changes) — 1%. Для патч-релизов — 5-10%. Первый этап должен быть достаточно мал, чтобы в случае ошибки impact был минимальным, но достаточно велик, чтобы получить статистически значимые метрики. 1% для приложения с 10 млн пользователей — 100 тыс. человек, достаточно для обнаружения критических проблем.
Нужно ли делать release party?
Release party (командное празднование) — опционально, но полезно для morale. Лучше проводить после успешного rollout на 100%, а не в момент загрузки билда. Release celebration можно совмещать с release retrospective, чтобы обсудить, что прошло хорошо, а что можно улучшить.
Кто отвечает за решение «релиз или отложить»?
Ответственность лежит на release manager (обычно senior engineer или tech lead). Решение принимается на основе данных с release dashboard, а не на основе дедлайна. Release manager имеет authority задержать релиз, если метрики не проходят go/no-go gate.
Итоги
- Релизный день — скоординированный процесс от code freeze до мониторинга после rollout
- Подготовка — release candidate, QA прогон, проверка метаданных, rollback план
- Staged rollout — 1% → 10% → 25% → 50% → 100% с go/no-go gate на каждом этапе
- Мониторинг — crash-free rate, ANR, error rate 5xx, user ratings в первые 4 часа
- Rollback — штатная процедура при падении crash-free rate ниже 99%
- Коммуникация — оповещение команды и стохолдеров до и после релиза
- Release retrospective — разбор процесса после завершения rollout на 100%
Мы разработаем мобильное приложение под ключ
IT Sectr создаёт приложения для iOS и Android для стартапов и бизнеса с 2017 года. Мы проконсультируем вас и предложим наилучшее решение.
Читайте также