📱 Приложения

Релизы и обновления приложений: версионирование, CI/CD, откаты

Релизы и обновления мобильного приложения требуют версионирования, CI/CD, поэтапного роллаута и плана отката. Разбираем процесс релиза в App Store и Google Play, частоту обновлений и управление рисками для РФ-рынка в 2026 году.

Денис Закаев, ИИ-архитектор, IDEA
Денис Закаев
ИИ-архитектор, IDEA
📅 2 июля 202611 мин👁
📱
Короткий ответ

Релизы мобильного приложения делают раз в 2–4 недели через версионирование, CI/CD и поэтапный роллаут. Главное — автоматизация сборки, тестирование на каждом этапе и план отката. Без процесса релизы превращаются в хаос с крэшами и негативом в отзывах.

Что такое релиз приложения

Релиз — это выпуск новой версии приложения в App Store и Google Play. Включает:

  • сборку билда,
  • тестирование,
  • публикацию в магазины,
  • поэтапный роллаут,
  • мониторинг метрик и крэшей,
  • план отката при проблемах.

Релиз — это процесс, а не событие. Чем он выстроен, тем стабильнее продукт.

Версионирование

Каждый релиз получает номер версии. Стандарт — Semantic Versioning: MAJOR.MINOR.PATCH, например 2.4.1.

Тип релизаКогда поднимаемПример
MAJORСущественные изменения, новая функциональность1.0 → 2.0
MINORНовые фичи, обратно совместимые2.4 → 2.5
PATCHБагфиксы, мелкие правки2.4.1 → 2.4.2

В App Store и Google Play есть два поля:

  • Version (видна пользователю) — например, 2.4.1.
  • Build number (внутренний) — инкрементируется при каждой сборке, например, 241.

Без уникального build number стор отклонит загрузку.

Типы релизов

Не все обновления одинаковы по содержанию и риску.

ТипСодержаниеРискРоллаут
HotfixКритический багфиксНизкий (точечный)Сразу 100%
PatchНесколько багфиксовНизкий10–50–100%
MinorНовые фичиСреднийПоэтапно 10–50–100%
MajorБольшое обновлениеВысокий5–20–50–100%

Чем выше риск, тем меньше стартовая доля роллаута.

CI/CD для мобильных приложений

CI/CD (Continuous Integration / Continuous Deployment) — автоматизация сборки, тестов и публикации. Без него релизы съедают 4–10 часов работы команды.

Что автоматизируют:

  • Сборка — из исходников в .aab/.ipa.
  • Тесты — unit, UI, интеграционные.
  • Подпись — автоматическая подпись сертификатами.
  • Выгрузка — в App Store Connect и Play Console.
  • Распределение — тестировщикам через TestFlight / Internal Testing.

Инструменты для РФ-рынка:

ИнструментТипЦена
FastlaneCLI, self-hostedБесплатно
BitriseОблакоот 8 000 ₽/мес
GitHub ActionsОблако (с self-hosted runner)Бесплатно до лимита
CodemagicОблакоот 6 000 ₽/мес
AppcircleОблакоот 5 000 ₽/мес

Для команды из 2–3 разработчиков Fastlane — достаточно и бесплатно. Для больших команд — облака экономят время на поддержку инфраструктуры.

Процесс релиза

Шаги зрелого релизного процесса:

1. Планирование

На спринте определяем, что входит в релиз. Формируем список тикетов, назначаем ответственных.

2. Разработка и code review

Каждая фича — в отдельной ветке, проходит code review, тесты. Слияние в основную ветку — только через pull request.

3. Сборка и автотесты

CI собирает билд при каждом pull request, прогоняет unit и UI-тесты. Не прошло — в основной ветку не попадает.

4. Ручное тестирование

На staging-сборке QA проверяет ключевые сценарии. Баги возвращаются в разработку.

5. Сборка релизного билда

CI собирает подписанный билд, выгружает в TestFlight (iOS) и Internal Testing (Android).

6. Бета-тест

5–20 тестировщиков или ранних пользователей проверяют релизную версию. 1–3 дня.

7. Публикация и роллаут

Отправляем в App Store/Google Play, запускаем поэтапный роллаут.

8. Мониторинг

Смотрим крэши, метрики, отзывы. Если что-то не так — откатываем.

Поэтапный роллаут

Это самый дешёвый способ снизить риск релиза.

В Google Play настраивается прямо в Play Console — указываем долю 10%, 20%, 50%, 100%.

В App Store — Stage Rollout (Phased Release) на 7 дней: 1, 2, 5, 10, 20, 50, 100% пользователей.

Стратегия роллаута:

ДеньДоляЧто проверяем
110%Крэш-рейт, ключевые метрики
2–350%Отзывы, воронки
4–7100%Все пользователи

Если на 10% крэш-рейт вырос вдвое или конверсия упала на 20% — ставим паузу и откатываем.

Откаты

План отката должен быть готов до релиза. Что делать, если что-то пошло не так:

  • Пауза роллаута. Останавливаем распространение в Play Console / App Store Connect.
  • Откат на предыдущую версию. В Google Play — кнопка Rollback. В App Store — отправка предыдущей версии как Critical Hotfix.
  • Серверная фича-флаг. Опасная фича выключается на бэке, без нового релиза.
  • Hotfix-релиз. Для критических багов — вне графика, 1–3 дня.

Лучший способ защиты — feature flags. Они позволяют включать/выключать функционал на лету, без релиза.

Мониторинг после релиза

Что отслеживать после выхода новой версии:

  • Crash-free rate. Должен быть выше 99,5%. Падение — сигнал к откату.
  • Conversion в ключевых воронках. Сравниваем с предыдущей версией.
  • Retention D1/D7. По когорте новой версии.
  • Отзывы в магазинах. Особенно в первые 3 дня.
  • Топ ошибок из аналитики. Crashlytics, AppMetrica.

Минимум неделя мониторинга после релиза, особенно если был Major.

Инструменты мониторинга

ИнструментЧто показываетЦена
AppMetricaКрэши, события, retentionБесплатно
Crashlytics (Firebase)Крэши по устройствам и версиямБесплатно
SentryОшибки фронтенда и бэкендаот 0
Instabug / BugseeОтчёты об ошибках с экранаот 5 000 ₽/мес

Связка AppMetrica + Crashlytics закрывает 95% задач мониторинга в РФ. Подробнее про метрики — в материале про аналитику приложения.

Частые ошибки релизного процесса

  • Ручная сборка. Секреты и сертификаты теряются, сборки едут у разных людей.
  • Нет автотестов. Каждый релиз — неделя ручного QA, баги проходят в прод.
  • Роллаут сразу 100%. Один крэш на всех — негатив в отзывах и падение рейтинга.
  • Нет плана отката. Когда горит — метаются, теряют часы и доверие пользователей.
  • Деплой в пятницу. Никто не хочет мониторить на выходных, и баг живёт 2 дня.
  • Игнор отзывов после релиза. Один негатив решает судьбу десятков установок.

Релизный календарь

Пример ритма для активного продукта:

ПериодРелиз
Каждый понедельникЗаморозка фичей в релиз
Вторник–средаТестирование
ЧетвергРелиз в сторы
Пятница–следующая неделяМониторинг

Крупные релизы (Major) выносят в отдельные даты, с бета-тестом 1–2 недели.

Релизы — это дисциплина. Чем чётче процесс, тем стабильнее приложение и спокойнее команда. Инвестиции в CI/CD и процесс отката возвращаются за 3–4 релиза экономией времени и спасённым рейтингом в магазинах.

Частые вопросы

Как часто выпускать обновления приложения?
Раз в 2–4 недели для активного продукта. Критические багфиксы — вне графика, в течение 1–3 дней. Реже раза в месяц — приложение кажется заброшенным, чаще — утомляет пользователей постоянными загрузками.
Что такое поэтапный роллаут?
Это выпуск обновления не всем сразу, а долей пользователей — например, 10% в первый день, 50% через день, 100% через 3 дня. Если на 10% появляются крэши или негатив, релиз откатывают без ущерба для остальных.
Как откатить неудачный релиз?
В Google Play — кнопкой Rollback в Play Console или паузой роллаута. В App Store — отправкой предыдущей версии в Review с пометкой Critical Hotfix, либо через Phase Rollout паузу. Иметь план отката нужно до релиза, не после.
Нужен ли CI/CD для мобильного приложения?
Да, если выпускаете регулярно. CI/CD автоматизирует сборку, тесты и выгрузку в сторы, экономит 4–10 часов на релиз и исключает человеческие ошибки. Инструменты — Fastlane, Bitrise, GitHub Actions.
Оцените материал:
0

Остались вопросы? Поможем

Эксперты IDEA ответят по теме материала или подскажут по вашему проекту. Свяжемся в течение дня, без навязывания.

Комментарии · 0