# Выпускайте обновления без сюрпризов

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/quality-release/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/quality-release/index.md
- **Раздел:** Качество продукта
- **Время:** 45 минут перед выпуском

Безопасный релиз — это заранее записанный ответ на три вопроса: что проверяем до публикации, кто смотрит первые сигналы и при каком условии останавливаем распространение.

## Результат

Одностраничная карточка релиза с затронутыми путями, проверками, владельцами, метриками и стоп-условиями.

## Релиз — это управляемая проверка, а не кнопка Publish

Даже небольшое изменение может сломать вход, аналитику или переход из уведомления. До публикации команда договаривается, какие пути затронуты, кто отвечает за первые часы и какой сигнал означает: продолжаем, останавливаем или откатываем.

## Что понадобится

- **Сборка:** Готовая версия на iOS и Android плюс предыдущая версия из стора для проверки обновления.
- **Команда:** Владелец релиза, мобильный разработчик или QA и контакт поддержки на период наблюдения.
- **Окно:** Минимум 60 минут до публикации на проверку и первые 2–4 часа после выпуска на мониторинг.

## Термины простыми словами

- **Crash-free rate — Доля пользователей без аварийного закрытия приложения:** Определение: Чем ближе показатель к 100%, тем меньше пользователей столкнулись с вылетом приложения за выбранный период. Пример: Crash-free users 99,5% означает, что 0,5% пользователей столкнулись хотя бы с одним вылетом.
- **ANR — Зависание Android-приложения:** Определение: Android фиксирует ANR, когда интерфейс слишком долго не отвечает на действия пользователя. Пример: Пользователь нажал кнопку, экран завис, и Android предложил закрыть приложение.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.
- **Deep link — Ссылка сразу на нужный экран приложения:** Определение: После нажатия пользователь попадает не на главную, а в конкретный сценарий, который был обещан в сообщении или на сайте. Пример: Push о сохранённом уроке открывает этот урок, а не домашний экран.
- **Конверсия — Доля людей, которые перешли к следующему шагу:** Определение: Показывает, сколько пользователей из начавших шаг завершили его или дошли до следующего. Пример: 80 завершили регистрацию из 100 начавших: конверсия равна 80 ÷ 100 × 100% = 80%.

## Когда применять

Перед каждым обновлением, особенно если меняются регистрация, хранение данных, уведомления, deep link или ключевой пользовательский сценарий.

## Что открыть до релиза

Соберите ссылки заранее. В момент проблемы команда не должна искать нужный дашборд или человека в переписке.

- **Список изменений**
  - **Источник:** Возьмите задачи релиза и переведите их в пользовательские пути: вход, регистрация, контент, операция, уведомление, профиль.
  - **Если доступа нет:** Если списка изменений нет, попросите каждого разработчика одним предложением назвать изменение и возможный затронутый экран.
- **Стабильность и события**
  - **Источник:** Подготовьте дашборды crash-free, ANR, ошибок API и ключевых событий для новой версии приложения.
  - **Если доступа нет:** Без дашборда назначьте человека, который проверит логи, тестовые аккаунты и обращения поддержки через 30, 60 и 120 минут.
- **Канал реакции**
  - **Источник:** Заранее укажите чат, владельца решения и способ остановить распространение либо быстро выпустить исправление.
  - **Если доступа нет:** Если технический откат невозможен, запишите безопасный план: остановка кампаний, выключение функции или сообщение пользователю.

## Подготовьте релиз за пять шагов

1. **Переведите задачи в пользовательские пути.** Не ограничивайтесь списком технических изменений. Назовите, что увидит пользователь и какой соседний сценарий может пострадать.
   - **Где сделать:** В верхней части карточки релиза рядом с версией.
   - **Пример:** Изменили авторизацию → проверяем вход, восстановление сессии, обновление со старой версии и deep link для незалогиненного пользователя.
2. **Проверьте чистую установку и обновление.** Новая установка и переход со старой версии — разные сценарии. Пройдите оба на iOS и Android с реальными тестовыми аккаунтами.
   - **Где сделать:** В тестовой сборке и версии из стора.
   - **Пример:** После обновления с 4.2 пользователь остаётся авторизован, история и настройки сохраняются.
3. **Пройдите критичные действия.** Проверьте вход, первое полезное действие, ключевую операцию, уведомление и возврат из фона. Запишите факт, а не «должно работать».
   - **Где сделать:** В чек-листе с датой, устройством и именем проверившего.
   - **Пример:** Android 13: регистрация пройдена 10 из 10 раз; событие completion видно в отчёте.
4. **Запишите стоп-условия.** До публикации определите конкретный сигнал, при котором распространение нужно остановить. Формулировка «если будет плохо» не помогает принять решение.
   - **Где сделать:** В последней колонке карточки релиза.
   - **Пример:** Останавливаем, если конверсия входа новой версии ниже обычной более чем на 10% или появляется потеря сессии.
5. **Назначьте наблюдение после выпуска.** Укажите владельца, интервалы проверки и канал реакции. Поддержка должна знать, что изменилось и какие данные приложить к обращению.
   - **Где сделать:** В чате и карточке релиза.
   - **Пример:** Проверки через 30, 60, 120 минут; владелец — Мария; поддержка добавляет версию приложения и ID пользователя.

## Примеры из практики

- **До публикации: обновление с 4.2:** QA обновляет версию из стора, проверяет сохранённую сессию и историю. Потеря входа или данных — заранее записанное стоп-условие, а не повод спорить после запуска.
- **После публикации: контрольные точки:** Release owner смотрит crash-free, ошибки входа и конверсию ключевого действия через 30, 60 и 120 минут; поддержка добавляет версию приложения к каждому новому обращению.

## Готовый артефакт: Карточка контроля релиза 4.3

Одна строка на проверку. Рядом сразу стоят владелец, факт и условие остановки.

| Проверка | Владелец | Ожидаемый результат | Стоп-условие |
| --- | --- | --- | --- |
| Обновление с 4.2 | QA | Сессия и данные сохранены | Потеря входа или данных |
| Чистая регистрация | iOS/Android | Код и профиль работают | Успех ниже 95% в тестах |
| Ключевое действие | Менеджер продукта | Событие и результат видны | Падение конверсии >10% |
| Deep link из push | CRM-специалист | Открывается нужный экран | Переход ведёт на ошибку |
| Первые 2 часа | Владелец релиза | Crash-free в обычном диапазоне | Резкий рост crash/ANR |

Решение принимает владелец релиза. При стоп-сигнале команда останавливает распространение, фиксирует время и версию, сообщает поддержке и выбирает откат либо срочное исправление.

## Чек-лист выпуска

Не отмечайте пункт заранее. У каждой проверки должен быть факт: устройство, время, результат или ссылка на дашборд.

- [ ] Изменения переведены в понятные пользовательские пути.
- [ ] Проверены чистая установка и обновление на iOS и Android.
- [ ] Критичные действия, аналитические события и deep link работают.
- [ ] Для ключевых метрик записаны стоп-условия и безопасный план реакции.
- [ ] Назначены владелец релиза, интервалы мониторинга и контакт поддержки.

## Что смотреть после релиза

- **Стабильность:** Crash-free, ANR и ошибки API новой версии не выходят за обычный диапазон.
- **Ключевой путь:** Вход, регистрация и главное действие проходят не хуже предыдущей версии.
- **Живые сигналы:** Поддержка и отзывы не показывают новый повторяющийся сценарий проблемы в первые 72 часа.

## Главное правило

Если команда не знает, кто и по какому сигналу остановит распространение, релиз ещё не готов к публикации.

---

- [HTML-версия](https://playbook.affpartners.io/ru/practices/quality-release/index.html)
- [Все практики](https://playbook.affpartners.io/ru/)