Выпуск остановлен: как обслуживать две версии приложения

Сначала уточните механизм магазина

Google Play staged rollout относится к обновлениям. Остановка прекращает дальнейшую выдачу версии в этом выпуске; уже обновившиеся пользователи остаются на ней. Доля распространения сама не увеличивается. Google: staged rollout.

Apple phased release распределяет автоматические обновления за семь дней. При этом любой пользователь может скачать обновление вручную. Паузами можно суммарно использовать 30 дней; продолжение идёт с остановленного дня. Apple: phased release.

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

Измерьте именно затронутую работу

Дальше рассматривается вымышленный Android-сценарий без реальных устройств и заказчиков. В выбранный момент в контрольной группе зафиксированы 100 установок: 80 используют A10, 20 — A11. За отдельное фиксированное окно A10 создала 10 заказов, A11 — 40. Получилось 50 заказов. Это заданные учебные наблюдения, а не обещание магазина или рыночная статистика.

Доля A11 среди установок: 20 ÷ 100 = 20%. Доля её заказов в данном окне: 40 ÷ 50 = 80%. Поэтому малый размер группы не показывает малую долю операционной работы. Один клиент может создавать несколько заказов; эти доли отвечают на разные вопросы и не требуют равенства.

В учебном сценарии staged rollout остановлен; 20 установленных A11 остаются предметом поддержки.

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

Постройте матрицу клиент × сервер

Зададим намеренно несовместимые учебные условия. A10 показывает обещанное время выдачи только из поля pickup_at. A11 понимает только pickup_window. Сервер S0 возвращает первое поле, S1 — второе. Каталог, заказ и обещание одинаковы; меняется представление, которое умеет читать программа. Это вымышленный протокол, а не описание SABSUS.

Для проверки предложен переходный Scompat: он выдаёт обе формы с одним согласованным смыслом. Само появление двух названий полей ещё не принимает реализацию: проверяются значения и экранное обещание. В таблице «да» означает только выполнение заданного условия чтения; весь заказ требует дальнейших проверок.

Возврат сервера к S0 помогает A10, но лишает A11 нужного поля. Поэтому поручение «откатить сервер» недостаточно. Техническая команда предлагает проверенное продолжение для обеих поддерживаемых сборок либо явно ограничивает затронутую новую операцию согласованным способом. Для уже принятых заказов нужен отдельный доступный путь.

Проследите один принятый заказ через обновление

Возьмём учебный O318, принятый в A10 до переключения. Покупатель затем открывает его в A11. По нашему заданному правилу подтверждённое обещание — выдача в 16:30 выбранной даты и часового пояса. Новый экран должен сохранить этот смысл; расширение до произвольного интервала нельзя молча считать эквивалентным.

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

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

Обычная свежая установка не воспроизводит весь случай. Нужна последовательность «принят заказ → изменена сборка → открыт существующий заказ». Отдельно проверьте новое оформление, повторный вход и возвращение после паузы. Сохраняйте ожидаемый и фактический результат, чтобы несовпадение не растворилось в общей отметке «приложение работает».

Дайте поддержке различимые случаи

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

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