Релиз и распространение

Всё, что происходит между «код готов» и «он у людей»: версионирование, проверка в сторе, поэтапная раскатка и то, что на мобильных релиз нельзя отозвать.

Почему это важно. Мобильные релизы работают только в одну сторону. Ошибку в вебе исправляют за десять минут; релиз в сторе ждёт проверки, а старые версии в любом случае остаются у пользователей месяцами. Эта асимметрия и должна определять то, как вы выпускаете приложение.

Что нужно понимать

• Кто сейчас сидит на какой версии и как долго будет на ней оставаться
• Как останавливают плохой релиз и насколько быстро это происходит
• Что обязано продолжать работать в самой старой поддерживаемой версии
• К чему придерётся проверка — до того, как сборка отправлена
• Что видит пользователь, когда его версию перестают поддерживать

Ключевые темы

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

• Имя версии и номер сборки — и почему их генерируют, а не вписывают руками
• Что версия сообщает пользователям, поддержке и системе сбора крешей
• Как сопоставить сборку с коммитом, из которого она собрана

Отправка в стор

• Правила проверки и типовые причины отказа
• Метаданные, скриншоты и декларации о приватности как часть релиза
• Сроки проверки и планирование с их учётом
• Ускоренная проверка — и почему её не тратят по пустякам

Раскатка

• Поэтапная раскатка и метрики, за которыми следят на каждом этапе
• Остановка раскатки — единственная настоящая отмена
• Исправление хотфиксом вперёд, а не откатом
• Бета-каналы и внутреннее распространение до всего перечисленного

Удалённое управление

• Feature flags: выкатить код и включить его — два разных решения
• Удалённая конфигурация и отключение сломанной функции без релиза
• Принудительное обновление как крайняя мера — и как сделать его не жестоким по отношению к пользователю
• Совместимость сервера со старыми клиентами — это та же самая задача

После релиза

• Наблюдение за частотой крешей и отзывами в первые часы
• Сравнение новой версии с предыдущей, а не с нулём
• Описание релиза, которое понятно любому

Уровни

Уровень	Как это выглядит
Junior	Собирает релиз, следует чек-листу отправки.
Middle	Ведёт версионирование и поэтапную раскатку, следит за метриками после релиза, использует флаги, чтобы отделить выкладку от запуска.
Senior	Проектирует процесс релиза целиком — стратегию отката, поддержку старых версий, принудительные обновления — и удерживает риск каждого релиза низким.

Практика

Для начала

• Проследите путь сборки Возьмите выпущенную версию и найдите точный коммит, из которого она собрана.

• Прочитайте правила Пройдите по правилам проверки стора и найдите два пункта, на которых ваше приложение может споткнуться.

• Напишите настоящее описание релиза Такое, которое поймёт пользователь, а не перечень внутренних названий.

Глубже

• Выкатите незаметно Выпустите функцию под флагом, а затем включите её без новой сборки.

• Раскатайте поэтапно Выпустите версию на небольшой процент пользователей, заранее определите, что заставит вас остановиться, и наблюдайте.

• Поддержите старый клиент Внесите изменение на сервере так, чтобы годовалая версия приложения продолжала работать, и докажите это.

Проверьте себя

• Какая самая старая версия вашего приложения ещё используется — и работает ли она до сих пор?
• Как вы остановите релиз, который падает, и сколько времени это займёт?
• Какие из последних релизов можно было заменить переключением флага?
• Что делает приложение, когда его версия API перестаёт поддерживаться?
• Как определить, из какой сборки пришёл отчёт о креше?
• Кто, кроме вас, может выпустить релиз?

Материалы

• Deploying to the App Store и to Google Play — официальные руководства Flutter, включая подпись и конфигурацию сборки.
• App Store Review Guidelines — сами правила. Разделы про сбор данных и удаление аккаунта стоит прочитать до первой отправки, а не после отказа.
• Google Play: release with confidence — поэтапные раскатки, тестовые треки и остановка релиза.
• Feature Toggles — длинная статья Пита Ходжсона о видах флагов, их жизненном цикле и о том, в какой беспорядок они превращаются, если их никогда не убирать.
• Semantic Versioning — соглашение, которое стоит знать точно, если вы публикуете не только приложения, но и пакеты.