Релизний день в розробці застосунків: суть, етапи та підготовка
Релизний день (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 і маркетингових матеріалів. Чим ретельніша підготовка, тим спокійніше проходить сам релизний день.
Чекліст підготовки до релизного дня включає: фінальний 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 — створення тега та збірка
# Передбачає, що code freeze вже активний
# Створити гілку release з develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: правила захисту гілок блокують нові PR
# Запустити regression suite в CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Створити тег release після успішного QA
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Зібрати бінар release через CI/CD
# fastlane build_release створює 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 року. Ми проконсультуємо вас і запропонуємо найкраще рішення.
Читайте також