Для приёмки важно разделять четыре вещи: метку Runner в workflow, фактически выданный образ, версию macOS и установленную версию Xcode. Указанное в задании имя Runner — это выбор среды, а не полный снимок её программного состава. Источник истины для конкретного запуска — сохранённая диагностика самого задания, сопоставленная с опубликованной записью образа.

GitHub сообщает о переходе Xcode 27 Runner на macOS 27 и публичном предварительном статусе. Это подтверждённое состояние на дату проверки, а не обещание, что состав образа останется неизменным. Описание Xcode 27 arm64 Runner Image и история выпусков Runner Images нужны для уточнения состава и изменений между публикациями.

Не считайте эти признаки взаимозаменяемыми:

• Метка Runner показывает, какой вариант вы запросили в workflow.
• Версия образа характеризует опубликованное окружение, выданное для задания.
• Версия macOS подтверждает системную базу выполнения.
• Версия Xcode и активный путь разработческих инструментов показывают, какой комплект реально вызвал сборку.
• Успех сборки подтверждает только конкретный шаг и конкретный запуск.
• Результат выпуска требует отдельного подтверждения архивирования, подписи и загрузки.

Чтобы получить воспроизводимую запись, добавьте диагностический шаг перед сборкой:

- name: Зафиксировать среду сборки
  run: |
    sw_vers
    xcodebuild -version
    xcode-select -p
    uname -m
    echo "ImageOS=${ImageOS}"
    echo "ImageVersion=${ImageVersion}"

Если значение переменной недоступно, не подставляйте ожидаемое значение вручную: сохраните то, что действительно вернул Runner, и отметьте пробел в диагностике. Для каждого запуска прикладывайте журнал, идентификатор задания, ревизию workflow и сведения о публикуемом образе. Сверяйте эти записи с каталогом Runner Images, а не только с названием метки.

Разделите проверку по ответственности. Так проще понять, кто подтверждает факт, кто принимает риск и где хранится доказательство. Одна зелёная отметка workflow не закрывает все этапы: у сборки, QA, подписи, публикации и эксплуатации разные критерии.

CI-ответственный: найти затронутые задания

Соберите перечень workflow, где выбирается Runner с Xcode 27. Включите не только основной pipeline, но и ручные релизы, ночные тесты, задачи подготовки архива, проверку pull request и вспомогательные задания. Уточните, какие из них собирают приложения для iOS, какие — приложения для macOS и какие загружают итоговый пакет.

Для каждого задания заведите запись с четырьмя полями: запрошенная метка, фактический образ, фактические версии macOS и Xcode, назначение задачи. Руководство GitHub по выбору Runner для задания workflow помогает проверить, как задан выбор среды. Не делайте вывод о версиях установленного ПО только по строке конфигурации workflow.

Команда приложения: доказать повторяемость сборки

Выберите проект, который представляет реальный профиль команды: тип приложения, способ разрешения зависимостей, скрипты сборки и используемые пакеты. Выполняйте проверку в отдельной ветке или непроизводственном workflow. Не меняйте одновременно базу macOS, зависимости и конфигурацию сборки — иначе при ошибке будет трудно установить причину.

Фиксируйте:

• состояние разрешения зависимостей и сообщения об изменениях;
• ошибки компилятора, предупреждения и настройки выбранного SDK;
• результаты unit-тестов и тестов, использующих симулятор;
• состав и контрольные признаки ожидаемого артефакта;
• точную версию проекта и конфигурацию задания.

Сравнивайте результат с последним принятым запуском того же проекта. Успех одного репозитория не доказывает совместимость остальных: разные проекты могут использовать разные зависимости, скрипты, настройки и этапы публикации. Если артефакты отличаются, выясните, обусловлена ли разница окружением или изменением проекта, и задокументируйте вывод до допуска workflow.

QA и выпуск: проверить путь от теста до загрузки

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

Требования к инструментам и минимальной системной среде сверяйте с официальной страницей системных требований Xcode. Условия подготовки к распространению проверяйте по документации Apple о подготовке приложения. Для загрузки артефакта используйте актуальное руководство по отправке сборок в App Store Connect, а для подписания macOS-кода — описание подписи для распространения.

Проверьте в собственном workflow, какие сертификаты, профили и секреты доступны заданию, как выбирается идентификатор подписи и кто имеет право запускать публикацию. Не переносите значения секретов в журналы при отладке. Если меняете контекст выполнения, отдельно подтвердите, что секреты по-прежнему доступны только нужным заданиям и что ручное подтверждение выпуска выполняется ответственным лицом.

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

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

1. Зафиксируйте исходную конфигурацию. Сохраните workflow, выбранную метку, ревизию репозитория, режим запуска и список заданий, использующих Xcode 27 Runner. Отметьте, какие задания имеют доступ к ключам подписи и могут загружать релиз.
2. Соберите фактические данные Runner. Выполните команды диагностики до любых изменений среды. Запишите версии macOS и Xcode, активный путь инструментов, архитектуру и сведения об образе, если они доступны.
3. Сверьте образ с опубликованной документацией. Сопоставьте фактическую запись с текущим README образа и выпуском Runner Images. Если описание не подтверждает нужный вариант среды или запись не совпадает с наблюдаемой, остановите допуск и выясните расхождение.
4. Прогоните репрезентативный проект в изоляции. Используйте тот же код, параметры сборки и источник зависимостей, что и в релизном процессе. Зафиксируйте разрешение зависимостей, компиляцию, тесты и различия артефакта.
5. Проверьте весь выпуск отдельно. Включите симуляторные тесты, архивирование, экспорт, подпись и загрузку, если соответствующие этапы входят в ваш процесс. Сохраните статус каждого этапа, а не только общий итог workflow.
6. Оформите решение и возврат. Назначьте владельца допуска, приложите доказательства и заранее укажите проверенный канал для возврата. Не переводите production на новый образ, пока ответственный не подтвердит и сборочную часть, и релизные этапы.

Для работы с Xcode 27 Runner полезно вести отдельную запись приёмки на каждую высокорисковую задачу. Она должна отвечать на практические вопросы: что запускалось, в каком образе, с каким результатом и кто разрешил использование в производственной публикации. Так команда сможет отличить ошибку проекта от изменения системной базы, а при инциденте — быстро определить, какой канал использовать вместо неподтверждённого.

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

Сначала разделите задачи по последствиям сбоя и требованиям к контролю. Один и тот же CI может использовать управляемый образ для проверок изменений, а выпускать продукт через отдельный, уже принятый канал. Это не означает, что один вариант всегда безопаснее: решение зависит от вашей политики, фактической приёмки и возможности быстро вернуться к известной среде.

Решение по условиям

• Если команда принимает предварительный статус, диагностика однозначно фиксирует образ и версии, а проверки проекта и выпуска пройдены, то оставьте подходящие задания на управляемом Runner с документированным допуском.
• Если проверка сборки успешна, но подпись или загрузка не подтверждены, то не переводите релиз на новую среду; используйте уже проверенный канал выпуска.
• Если производственная политика требует закреплённой и управляемой базовой системы, а текущий Runner не даёт нужных контрольных доказательств, то сохраняйте проверенный выделенный Mac-канал.
• Если возвратный путь не проверен на реальном workflow, то не начинайте производственный переход, пока не подтвердите его работоспособность.
• Если у вас нет подтверждённых данных о конфигурации или восстановлении предлагаемого узла, то не принимайте решение о его пригодности по названию услуги или предполагаемым возможностям.

Плюс управляемого Runner — меньше операций по самостоятельному ведению узла, когда его среда подходит и принята. Минус — вам необходимо следить за публикуемым образом и повторять проверки при существенных изменениях. Выделенный Mac может дать вашей команде отдельный контур ответственности, но он не отменяет обслуживания, контроля доступа, фиксации версий и регулярной проверки восстановления. Сам по себе выделенный статус не доказывает ни стабильность, ни соответствие требованиям.

Рассматривая удалённый Mac для этой роли, запросите и проверьте именно те сведения, которые нужны вашей приёмке: доступные macOS и Xcode, конфигурацию, срок аренды, регион узла, способ доставки доступа и подтверждённые записи сброса или восстановления. Не подменяйте отсутствующие данные обещаниями и не переносите на новый канал результаты теста, выполненного в другом окружении.

Какую среду выбирать, если метка Runner не менялась?

Считайте неизменной только конфигурацию запроса, а не весь образ. В начале задания сохраните фактические сведения о macOS, Xcode и Runner, затем сопоставьте их с текущим описанием опубликованной среды. Если образ или его версия не подтверждены, приостановите производственный допуск. Для релизной задачи используйте проверенный возвратный канал, пока расхождение не объяснено.

Достаточно ли успешной сборки, чтобы считать macOS 27 принятой для CI?

Нет. Сборка не проверяет автоматически весь путь до пользователя. Отдельно пройдите зависимости, компиляцию, нужные тесты, создание архива, экспорт, подпись и загрузку. Зафиксируйте результаты каждого этапа и сравните их с принятой командой базовой записью. Допуск распространяйте только на те репозитории и workflow, которые реально проверены, а не на все проекты организации.

Как учесть публичный предварительный статус при планировании релиза?

Сверяйте текущий статус непосредственно с объявлением GitHub и не считайте его постоянным. Затем примените внутреннюю политику: организация может принять предварительную среду после собственной приёмки, но может потребовать для выпуска более контролируемый канал. В решении укажите владельца, доказательства, затронутые задачи и способ возврата. Не делайте вывод о пригодности для production только из факта существования образа.

Какие требования Apple проверять перед загрузкой приложения?

Проверяйте актуальные системные требования Xcode и сопоставляйте их с используемой конфигурацией. На практике подтвердите полный маршрут: архив, экспорт, подпись выбранными командой сертификатами и профилями, загрузка и итоговый статус. Документация Apple задаёт ориентир, но итоговое доказательство для вашей команды — успешная проверка реального процесса в целевой среде.

Не смешивайте доступность узла, успешность CI-задания и завершённую публикацию: это разные состояния. Для каждого укажите отдельное подтверждение и ответственного. Пока запись среды не сопоставлена с образом, ключевые задачи не проверены, а возврат не отрепетирован, оставьте production на ранее принятом канале. Если приёмка пройдена, допускайте только проверенные workflow и сохраняйте материалы, по которым можно восстановить причину сбоя.

Для настройки контрольной среды сначала полезно определить требования к базовой конфигурации удалённого Mac в KVMNODE, а затем сверить доступные варианты через страницу заказа Mac. Рассматривайте отдельный Mac как вариант для задач, где вам действительно нужна проверенная и закреплённая рабочая база, а не как автоматическую замену любого Runner. Если вы оцениваете KVMNODE для выпуска, принимайте решение только после подтверждения актуальных версий среды, условий доступа и реальных записей восстановления; не подменяйте эти проверки неподтверждёнными обещаниями.