На 5 сентября 2026 года GitLab Hosted macOS Runner нельзя считать готовой единственной средой для производственной миграции на Xcode 27: в официальном списке GitLab ещё нет образа Xcode 27. На этой неделе оставьте стабильные сборки и несекретные проверки в Hosted Runner, а для Xcode 27, приватной сети и финальной подписи выделите отдельный self-hosted Mac и подтвердите решение реальными заданиями.
Этот материал предназначен для руководителей разработки и DevOps, которые планируют переход на Xcode 27 и должны проверить границы GitLab CI/CD. Он также будет полезен IT-руководителям, отвечающим за кодовую подпись, внутренние зависимости и сетевую изоляцию, а также техническим директорам и закупщикам, сравнивающим полную стоимость Hosted Runner и собственного Mac.
Важно: статус Hosted Runner, состояние конкретного macOS-образа и жизненный цикл Xcode — это разные параметры. Появление Xcode 27 Beta у Apple не означает, что Xcode 27 уже доступен в образе GitLab.
Последнее обновление: 5 сентября 2026 года. Данные сверены с официальной документацией GitLab по Hosted macOS Runner, Hosted Runner, Compute Minutes и установке GitLab Runner, а также с примечаниями к выпуску Apple Xcode 27.
SECTION 01 Версия Xcode и доступность образа
На дату проверки документация GitLab помечает Hosted runners on macOS как Beta и перечисляет образы с macOS 15/Xcode 16 и macOS 26/Xcode 26. Образ с Xcode 27 в опубликованной матрице отсутствует. Это не прогноз и не вывод из обсуждений сообщества, а граница официально заявленной доступности в документации GitLab Hosted macOS Runner.
Apple при этом уже публикует официальные примечания к выпуску Xcode 27, включая материалы Beta-серии. Для руководителя это создаёт конфликт версий:
- Xcode 27 может быть необходим для проверки SDK и поведения будущей версии платформы;
- Hosted Runner может предоставить только более раннюю комбинацию macOS и Xcode;
- состояние Beta у сервиса не является обещанием даты появления следующего образа;
- наличие образа в будущем ещё не доказывает соответствие требованиям вашей подписи, сети и аудита.
Поэтому вопрос следует формулировать не как «есть ли Xcode 27 у Apple», а как «можно ли воспроизводимо выполнить наш pipeline на образе, который разрешён GitLab и принят нашей службой безопасности». Пока ответ на первую часть отрицательный, полный перенос производства на Hosted macOS Runner создаёт версионную зависимость, которую вы не контролируете.
Календарь контрольных точек
В день планирования адаптации зафиксируйте текущую матрицу GitLab и Apple в репозитории инфраструктуры. После официального добавления нового образа повторите проверку на конкретном проекте, а не ограничивайтесь изменением названия в документации.
Проверка должна включать:
- точную версию macOS и Xcode;
- доступные Simulator Runtime и SDK;
- версию Swift Package Manager и сторонних инструментов;
- возможность установки требуемых сертификатов;
- прохождение полного цикла от checkout до archive и export;
- повторяемость результата на следующем запуске.
Официальное описание Hosted Runner нужно использовать именно как источник текущих правил сервиса, а не как гарантию будущей поддержки Xcode 27. Если GitLab изменит образ или его статус, матрицу следует пересмотреть до включения нового тега в production.
SECTION 02 Контроль инструментальной цепочки
Предварительно установленный набор инструментов сокращает время подготовки задания, но не даёт вам полного контроля над моментом обновления. Вы выбираете доступный образ, а не управляете его жизненным циклом. Это важное отличие от self-hosted Mac, где можно вручную установить требуемую версию Xcode и сохранить её до завершения окна совместимости.
Вместе с тем собственный узел не становится воспроизводимым автоматически. Администратор может обновить Xcode, заменить Simulator Runtime или изменить системные зависимости без записи в конфигурации. Если разные Runner регистрируются вручную, один и тот же commit способен пройти на одном узле и завершиться ошибкой на другом.
Для GitLab CI/CD зафиксируйте отдельный inventory:
- идентификатор узла и назначенную роль;
- macOS, Xcode, SDK и Simulator Runtime;
- версии Ruby, Bundler, CocoaPods или Swift Package Manager;
- инструменты архивации, экспорта и проверки подписанного приложения;
- доступные переменные CI/CD и их область действия;
- дату последнего изменения и ответственного владельца.
Полезно хранить этот список рядом с конфигурацией pipeline и выводить его в диагностический job без раскрытия секретов. Так вы сможете отличить ошибку проекта от дрейфа среды.
Повторяемость сборки
Проверка должна опираться на один и тот же commit и один и тот же набор задач. Запустите чистую сборку, сборку с кэшем, тесты на требуемом Simulator Runtime и архивирование. Затем повторите pipeline на том же типе узла и сравните:
- полученный archive;
- список предупреждений и ошибок;
- хэш или контрольные признаки артефактов, если процесс это допускает;
- продолжительность стадий;
- содержание логов установки зависимостей;
- итоговый статус подписи.
Не используйте рекламное название аппаратной платформы как доказательство совместимости. Даже Apple Silicon не гарантирует, что конкретная версия инструмента, бинарная зависимость или внутренний пакет ведёт себя одинаково на всех узлах. Для версионно чувствительного проекта сначала установите контроль над Xcode и SDK, затем измеряйте скорость.
SECTION 03 Безопасность подписи и разделение задач
Основная граница проходит не между «облаком» и «собственным железом», а между задачами с разным уровнем доверия. Компиляция открытого проекта, тестирование и проверка линтеров имеют другой риск-профиль, чем экспорт IPA с сертификатом распространения и доступом к App Store Connect.
Временная среда Hosted Runner может быть удобна для обычных проверок, однако корпоративная политика должна отдельно ответить на следующие вопросы:
- где и как появляются сертификаты и provisioning profile;
- кто контролирует переменные, передаваемые job;
- доступен ли Keychain в требуемом режиме;
- удаляется ли рабочая область после задания;
- какие логи и артефакты сохраняются;
- можно ли доказать отсутствие секретов в кэше;
- допускает ли аудит использование общего пула.
Документация GitLab описывает модель Hosted Runner, но решение о продуктивной подписи остаётся вашей зоной ответственности. Наличие команды xcodebuild archive ещё не означает, что узел соответствует внутренним требованиям.
На выделенном self-hosted Mac вы получаете больше контроля, но вместе с ним — больше обязанностей. Нужно ограничить доступ к Runner, изолировать Keychain, запретить интерактивное использование продуктивной учётной записи, вести журнал изменений и очищать рабочую область после задания. Ключи нельзя считать безопасными только потому, что Mac находится в вашем управлении.
Практичная схема разделения выглядит так:
- Hosted Runner — компиляция, unit-тесты, статический анализ и проверки без продуктивных секретов;
- отдельный self-hosted Mac — Xcode 27 Beta, внутренние зависимости и специальные Simulator Runtime;
- доверенный выделенный узел — archive, export и публикация, если этого требует политика;
- ручное одобрение перед этапом, который получает продуктивные credentials.
Подробные требования к ротации сертификатов подписи iOS стоит использовать как часть общей процедуры, но не подменять ими оценку самого Runner. Сертификатная политика и изоляция CI-узла решают разные задачи.
SECTION 04 Приватная сеть и границы данных
То, что Hosted Runner может получить исходный код, не доказывает доступ к полной цепочке сборки. Проект может зависеть от внутреннего CocoaPods-репозитория, приватного Swift Package Registry, корпоративного API, прокси, фиксированного исходящего IP или хранилища артефактов с белым списком адресов.
Перед выбором узла нарисуйте поток данных от job до каждого endpoint. Для каждой зависимости отметьте:
- направление соединения;
- DNS-имя и порт;
- необходимость VPN или прокси;
- разрешённый исходящий адрес;
- тип передаваемых данных;
- журналирование и срок хранения;
- требования к региону размещения.
Затем создайте негативный тест: намеренно ограничьте доступ к одному внутреннему endpoint и убедитесь, что pipeline завершается понятной ошибкой, а не зависает до исчерпания времени. Отдельно проверьте, не попадает ли содержимое приватных пакетов в логи и кэш.
Self-hosted Mac обычно проще включить в существующую сеть, но простота маршрутизации не заменяет согласование с безопасностью. Нужны правила firewall, сегментация, ограниченный доступ администратора и процедура восстановления после компрометации. Если узел имеет постоянный исходящий адрес, его нужно контролировать как критичный сетевой актив.
До закупки или аренды узла подготовьте три доказательства:
- схему сетевого потока с владельцами endpoint;
- список разрешённых адресов и исключений;
- подпись службы безопасности под результатами тестового pipeline.
Без этих документов решение «подключается к GitLab» слишком слабое для корпоративного допуска.
SECTION 05 Очередь, пропускная способность и восстановление
Цена и доступность узла не отражают его реальную производительность. Для Hosted Runner вы должны учитывать ожидание, фактическое выполнение и вычислительное потребление. GitLab описывает правила расчёта Compute Minutes; используйте их вместе с данными корпоративного счёта, а не заменяйте ими измерение времени в pipeline.
Для self-hosted Mac ключевым показателем является эффективная доступная ёмкость:
эффективная ёмкость = доступное время узла × доля успешных запусков − обслуживание − простой из-за блокировок.
Это не паспортная производительность. В расчёт следует включить ручное одобрение подписи, очистку Keychain, установку зависимостей, перезапуск Runner и время восстановления после неудачного обновления.
Тестовый набор должен отражать реальную смесь задач:
- pull request с быстрыми тестами;
- полный набор unit- и UI-тестов;
- архивирование;
- экспорт релизного артефакта;
- повторный запуск после ошибки;
- параллельные задания в пиковый период.
Один чистый билд на свободном узле не позволяет определить размер пула. Зафиксируйте для каждого задания время ожидания, время выполнения, размер кэша, частоту ошибок и время восстановления. Если у вас нет таких записей, количество необходимых узлов остаётся гипотезой.
Для контроля состояния собственного пула можно использовать GitLab Runner Fleet Dashboard, а установку приложения выполнять по официальной инструкции GitLab Runner для macOS. Эти документы помогают организовать эксплуатацию, но не заменяют нагрузочный тест на вашем проекте.
SECTION 06 TCO и матрица выбора
Сравнивайте не цену минуты с ценой Mac, а полную стоимость результата. Для Hosted Runner модель может выглядеть так:
TCO_hosted = вычислительное потребление × тарифная ставка + хранение артефактов + сетевые расходы + стоимость ожидания или простоя.
Для собственного узла:
TCO_self-hosted = амортизация или аренда + размещение + администрирование + мониторинг + обслуживание Xcode + резервирование + стоимость простоев + безопасность.
Тарифную ставку, коэффициенты и лимиты берите из актуального счёта и правил GitLab, поскольку они могут измениться. Для аренды используйте фактическое коммерческое предложение, а не примерную цену из статьи. Если вы рассматриваете удалённый Mac, запросите условия доступа, период аренды, права администратора, процедуру восстановления и ограничения сети; актуальные тарифы VPSNIX следует сверять непосредственно перед расчётом бюджета.
| Критерий | Hosted macOS Runner | Выделенный self-hosted Mac |
|---|---|---|
| Xcode 27 на дату проверки | Не указан в официальной матрице | Можно установить и зафиксировать после проверки совместимости |
| Контроль обновлений | Ограничен жизненным циклом образа | Определяется вашей процедурой изменений |
| Приватные зависимости | Требуют проверки маршрутизации и белых списков | Можно включить в корпоративный сетевой контур |
| Продуктивная подпись | Допуск зависит от политики и модели среды | Больше контроля, но больше ответственности |
| Пиковая нагрузка | Удобна эластичность, но нужно измерять очередь | Ёмкость ограничена пулом узлов |
| Обслуживание | Меньше задач на вашей стороне | Обновления, мониторинг и восстановление — ваша зона |
| Бюджет | Считается по фактическому потреблению и правилам GitLab | Считается по полной стоимости владения |
Условия принятия решения
Используйте следующую ветвящуюся проверку, а не универсальную рекомендацию:
- Если pipeline требует Xcode 27 уже сейчас, то направьте его на изолированный self-hosted Mac; иначе оставьте стабильную версию в Hosted Runner.
- Если job обращается к приватным endpoint или требует фиксированный исходящий IP, то выбирайте узел в контролируемом сетевом контуре; иначе сначала подтвердите доступность каждого endpoint из Hosted Runner.
- Если job использует продуктивные ключи подписи, то допускайте его только на узел, прошедший аудит; иначе Hosted Runner может обслуживать проверочный этап без секретов.
- Если нагрузка резко меняется и задачи не содержат чувствительных данных, то Hosted Runner может дать нужную эластичность; иначе рассчитывайте резервный self-hosted Mac.
- Если собственный узел простаивает большую часть времени, то сравните аренду или Hosted Runner с полным TCO; иначе проверьте, не дешевле ли управляемый постоянный пул.
- Если два последовательных запуска на одном commit дают разные результаты, то сначала исправьте контроль среды и кэша, а не расширяйте количество узлов.
Итоговая схема для большинства предприятий — не выбор одного поставщика, а два пула с разными правилами. Hosted Runner принимает стабильную инструментальную цепочку и проверки без секретов. Self-hosted Mac принимает Xcode 27, внутренние зависимости и задачи, где необходимы контролируемые Keychain и сеть.
SECTION 07 Переход от проверки к рабочему пулу
До изменения production-конфигурации выполните последовательность из восьми шагов:
- Снимите официальный снимок матрицы GitLab и Apple с датой проверки.
- Разделите pipeline на компиляцию, тесты, архивирование, экспорт и публикацию.
- Присвойте каждой стадии уровень чувствительности и требуемую версию Xcode.
- Зарегистрируйте один изолированный self-hosted Mac, не подключая его сразу к продуктивной подписи.
- Повторите на нём реальные pull request, тесты и архивирование с тем же commit.
- Проверьте доступ к внутренним пакетам, прокси, белым спискам и хранилищу артефактов.
- Проведите тест восстановления: остановка Runner, очистка рабочей области, повторная регистрация и повторный запуск.
- Сравните фактическую очередь, время выполнения, ошибки и стоимость с Hosted Runner, после чего утвердите правила маршрутизации.
Для эксплуатации зафиксируйте владельца каждого пула, окно обновления Xcode, процедуру отката, срок хранения логов и критерий остановки миграции. Если Apple выпустит Xcode 27 RC или финальную версию, а GitLab добавит новый образ, не меняйте production-тег автоматически: повторите матрицу совместимости и подпишите новое исключение безопасности.
SECTION 08 Ответы на вопросы закупки
Подробные ответы вынесены в отдельный блок, потому что решение зависит не только от номера Xcode, но и от доступа к данным, секретам и внутренним системам.
Практический итог
Сейчас не следует строить производственный план, в котором GitLab Hosted macOS Runner является единственным исполнителем Xcode 27. Неподтверждённый образ, Beta-статус сервиса и отсутствие контроля над моментом обновления создают слишком много переменных для критичных релизов.
При этом полностью отказываться от Hosted Runner также нерационально. Он может обслуживать стабильные версии, обычные тесты и несекретные проверки, пока отдельный Mac проходит проверку Xcode 27, сети, подписей и восстановления. Такой подход позволяет не покупать избыточный пул до появления измерений.
Если текущая схема основана на локальных Mac разработчиков или случайно настроенном Linux-узле, её слабые места обычно очевидны: нет гарантии одинакового Xcode, трудно контролировать доступ к Keychain, внутренние зависимости требуют ручных исключений, а восстановление после сбоя зависит от одного человека. Временная аренда выделенного Mac через VPSNIX может дать более предсказуемую точку для PoC: вы проверяете GitLab Runner, права доступа, сетевой маршрут и реальный pipeline до решения о расширении пула. Для параметров подключения и ограничений сначала изучите центр помощи VPSNIX, а не закладывайте неподтверждённые характеристики в TCO.
Начните с одного узла и измеримого теста: Xcode 27, продуктивная граница подписи, приватные endpoint, очередь, повторный запуск и восстановление. Если результаты подтверждают требования проекта, расширяйте пул; если нет — возвращайте только подходящие стадии в Hosted Runner и не смешивайте их с задачами, которым нужен доверенный Mac.