Релиз / Ops 28 апреля 2026

2026‑04‑28 · Фазовый релиз App Store, поезда TestFlight и чек‑лист выката на арендованном Apple Silicon‑облачном Mac (HK / JP / KR / SG / US)

Команда инженеров MacXCode 28 апреля 2026 ≈21 мин чтения

Релиз‑менеджеры, которые по SSH заходят на арендованный Mac mini M4 в Сингапуре или Токио и запускают xcodebuild archive, уже балансируют двумя разными «медленными» системами: TestFlight (бета, тестировщики, обработка сборок) и клиентским путём обновления App Store (фазовый или мгновенный). Фазовый выпуск обновлений App Store — часто описываемый как семидневная доля для пользователей автообновлений — не функция TestFlight; тем не менее один и тот же ранбук дежурства, статус‑канал в Slack и Git‑тег должны совпасть. Ранбук 2026‑04‑28: (1) делит ответственность между внутренними/внешними кольцами TestFlight и продуктовой версией App Store; (2) называет артефакты build train (один commit → один CFBundleVersion / семейство build), которые нельзя ломать ветвлением; (3) даёт цифровой чек‑лист, который ваш CI может логировать рядом с автоматизацией экспорт IPA и App Store Connect API. Вместе с headless Archive и подписью и порогами покрытия xcodebuild, когда нужно доказать: фазовая сборка совпадает с тестовой.

TestFlight и App Store: две аудитории, один набор инструментов

TestFlight — место, где продукт и QA доказывают поведение людям (внутренние, затем внешние), пока очередь processing, entitlement и метаданные export compliance всё ещё в истории. Клиентские обновления App Store — всё разом или фазовые — относятся к записи версии в Store, не к бете. Классическая ошибка: включён фазовый App Store, а маркетинг всё ещё ссылается на номер сборки TestFlight, которая этим поездом в витрине не будет. Фиксируется лексика: в тикетах пишите «сборка TF» против «версия Store 3.2.1 (8)».

  • TestFlight — обычно 100–10 000 внешних тестировщиков; быстрые итерации по крэш‑логам и фидбеку, затем промоут победившей сборки к релизу.
  • App Store — пара версия продукта + build в App Store Connect; фазовый релиз задаёт, как обновление за неделю доходит до авто‑обновлений.

7‑дневная фаза App Store (ключевые цифры)

Опубликованный Apple график увеличивает долю пользователей автообновлений изо дня в день. Ручные апдейтеры и новые установки часто получают последнюю версию сразу — в макросах поддержки должны быть обе аудитории. Типичный паттерн: день 0 включаете фазу и наблюдаете безкраш‑сессии; дни 1–2 — быстрейшие петли фидбэка; к дням 3–4 смотрим, доминируют ли тикеты старых iOS‑срезов, а не сюрпризы по entitlement. Пауза — это полноценное состояние: оформляйте как формальный инцидент — кто согласовал, как долго и какие скрины/ответы ASC API приложены.

Факт: если дежурные не могут ответить «какая именно сборка сейчас фазируется» за 30 секунд, почти всегда в тикете релиза нет тега, а не «не хватает возможностей Mac». Храните id версии и состояние фазы в ранбуке, а не только в DM.

Что всё ещё на арендованном сборочном хосте

Ни одна фазовая машина состояний App Store не снимает с вас обязанность архивировать, экспортировать и подписать IPA на доверенном хосте. Арендованный Mac mini M4 в HK / JP / KR / SG / US остаётся истиной сборки: то же лицо codesign, что проверено в выборе Xcode на job, и параметры ExportOptions.plist из ранбука экспорта должны быть тем же, что App Store Connect заглотает до любого переключателя фазы.

«Build train» в живой команде: один дирижёр

Build train — это одна линейная последовательность релиз‑кандидатов линейки продукта, где не больше одного кандидата «садится» на App Store за раз. Сбой распределённых команд: два релиз‑менеджера заливают разные IPA в один день, потому что релиз и хотфикс оба «зелёные» CI на разных pod. Минимальная дисциплина 2026 на загруженном SSH‑хосту: любой merge в release/x.y, который триггерит Archive, поднимает CFBundleVersion в одном коммите под защитой CI — как гигиена self‑hosted‑раннера, которая у вас уже есть.

git tag v3.2.1-build-4821 # тот же тег у записи сборки ASC и в пути CI‑артефактов

Матрица: от «CI зелёный» до «клиент обновился»

Канал Что доказывает Типичные ограничения
CI PR (сим + unit) Компилятор + тесты на закреплённом SDK Merge при красном блокировать — см. headless‑тесты и пороги покрытия
Внутренний TestFlight Дымовые проверки, entitlement, человеческие флоу Две удачные ночи на той же сборке до внешних
Внешний TestFlight Шире парк + метаданные App Review Поэтапные когорты тестировщиков; без‑крэш > 99,0 % на вашей основной метрике
App Store (фаза или полностью) Витрина, юридическое и региональные цены Подпись дежурных и продукт‑менеджера на плейбуки отката и паузы

Ранбук из 9 шагов: архив во вторник → спокойствие к пятнице

  1. Заморозить ветку — после cut без «случайных» CocoaPods/SwiftPM‑резолвов; перечитайте дисциплину кэша.
  2. Archive на релизном лейбле арендованного Mac с залогированным xcodebuild -version и предварительной проверкой подписи.
  3. Экспорт IPA через проверенный ExportOptions.plist и загрузку по API как в руководстве по экспорту — не разовый Transporter для CI.
  4. Отслеживать обработку в App Store Connect; выдавать buildProcessingState или аналог в лог‑мост в Slack; при ошибках вида ITMS-… падать быстро с сырым JSON.
  5. TestFlight — сначала внутренний; собрать 2 рабочих дня крэш‑логов без всплесков sev‑2.
  6. Внешняя когорта с письменным брифом (особенно для 14‑дневных первых установок).
  7. Версия App Store: заметки к релизу, изменения скриншотов при необходимости, затем фаза или сразу по аппетиту к риску.
  8. Фаза включена: кто может ставить паузу (две роли разных команд), максимально допустимая пауза (контекст лимита 30 дней Apple), когда «выпустить всем».
  9. После релиза: разбор если метрика расходится с базисом более чем на 0,3 % по без‑крэшу на день 2 — часто entitlement, а не «не повезло в SG».
Часовые пояса: дата и время выпуска в App Store Connect общие для всех — если дежурный в Восточной США, а архив по ветке в локальном Японии, занесите UTC и локальное в тикет. Иначе классика — «думал, вчера уже выкатили».

API App Store Connect, панели ops и доказательства

Командам с автоматизацией в 2026 не нужно трижды всматриваться в UI — они тянут ресурсы версий ключами JWT, как уже описано для CI, и мапят phased release state на дашборды. Навык: роли ключей API уже насколько позволяет соответствие, ротация в одном темпе с сертификатами CI‑подписи; никаких ключей в истории shell общего пользователя SSH — та же гигиена, что для headless‑подписи и моделей доступа. Если read‑доступ к API пока не подключён — хотя бы ночной снимок UI ASC в бакет артефактов для аудита в PNG со штампом времени.

FAQ: «мы в фазе?» без пяти созвонов

Вопрос Практичный ответ 2026‑04‑28
Отгрузили хотфикс при активной фазе App Store — что дальше? Остановиться, прочесть актуальную документацию Apple (старые треды могут быть до смены политики); на практике нужна новая версия приложения и решение остановить текущий поезд — решение зафиксировать; не отправлять второй номер сборки «наугад».
Различается ли фаза в малых регионах? Объём пользователей разный по приложениям; при сильной локализации мониторьте регионально крэши и зависания — кластеры HK / JP / KR / SG / US типично совпадают с MacXCode и ожиданиями ревью Apple.

Зачем в этой истории снова Mac mini M4 на Apple Silicon

Скорость релиза зависит от того, как быстро вы доверяете последнему «зелёному» пайплайну: bare‑metal‑Mac mini M4 в регионе даёт предсказуемые времена xcodebuild, честный I/O крупных .xcarchive и ровную «часики» под подписание кода до того, как App Store Connect получит хоть байт. Виртуальные общие runner’ы возможны — но когда в пятницу промо зависит от волны 03:00 UTC и оператора из Сеула, следящего за крашами, чем меньше лишних узлов у сборочного хоста — тем меньше паники с VNC. Узлы MacXCode 1–2 ТБ между Гонконгом, Токио, Сеулом, Сингапуром и США масштабированы так, чтобы ветка релиза и фазовый клиентский сценарий не делили один и тот же NVMe в одну и ту же пятницу.

Релизы рядом с тестировщиками, а не там, где важнее только латентность

1–2 ТБ · Apple Silicon · SSH / опционально VNC