Материал предназначен для технических руководителей, которые планируют переход на Xcode 27 и парк сборочных машин Apple Silicon. Вы сможете сформировать измеримую базу для закупки, а не защищать бюджет предположениями.

Он также полезен командам, обслуживающим GitHub Actions, Jenkins или другой CI-контур. Здесь показано, как превратить длину очереди и длительность workflow в требования к Mac-узлам.

Руководители бюджета и закупок получат критерии приёмки удалённых Mac, границы расширения и условия, при которых от покупки следует перейти к пилоту или смешанному пулу.

Последнее обновление: 23 сентября 2026 года. Данные сверены с примечаниями Apple для Xcode 27, документацией GitHub по Runner, ограничениям и тарификации. Перед закупкой повторно проверьте эти страницы: состояние образов, лимиты и правила оплаты меняются.

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

Узел занят, но процессор не является пределом

Чистая сборка может ждать checkout, разрешения зависимостей или загрузки артефактов. Симуляторные тесты могут упираться в память и дисковый ввод-вывод. Подписание — в доступность ключей, сертификатов и последовательность операций.

Поэтому показатель «загрузка CPU» нельзя использовать как единственный критерий расширения. Записывайте отдельно:

• время ожидания в очереди;
• время подготовки рабочего каталога;
• checkout и восстановление кэша;
• компиляцию;
• тестирование на симуляторе;
• архивирование;
• подписание и публикацию;
• повторный запуск после ошибки.

Команда не равна параллелизму

Десять разработчиков не означают десять одновременно работающих сборок. Один pull request может запустить несколько независимых job, а релизное задание может заблокировать тот же сертификат для остальных workflow.

Разделите поток минимум на четыре логических типа: PR-сборки, ночная регрессия, архивирование с подписью и публикация. Для каждого типа определите интенсивность поступления задач, продолжительность, пиковое окно и допустимое ожидание.

Секреты и сеть ограничивают доступную ёмкость

Сборочная машина может быть свободна, но не готова принять задачу. Причины — недоступный приватный registry, сетевой allowlist, лимит одновременного обращения к сервису или занятой signing key.

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

Эластичный узел не равен мгновенному узлу

При расширении учитывайте не только время выполнения job. В полный цикл входят запуск машины, установка или проверка инструментов, регистрация Runner, доставка секретов, восстановление кэша и health check.

В GitHub Actions метка xcode-27 уже описана в документации выбора Runner, но конкретное состояние образов, доступность возможностей arm64 и организационные ограничения необходимо проверять в момент планирования. Документация GitHub по выбору Runner не заменяет проверку собственного workflow.

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

Обозначим:

• λᵢ — число задач типа i, поступивших в выбранное окно;
• Tᵢ — фактическая длительность задачи типа i;
• Wᵢ — допустимое ожидание в очереди;
• Rᵢ — доля повторных запусков;
• Cᵢ — число задач этого типа, которые могут выполняться одновременно;
• S — резерв на недоступность узлов и плановые операции.

Тогда базовый спрос по типу задачи можно оценивать как:

Dᵢ = λᵢ × Tᵢ × (1 + Rᵢ)

Это не готовое число Mac, а нормализованная нагрузка. Для закупки сравнивайте её с пропускной способностью одного проверенного узла в том же типе задания.

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

P = max(D_PR, D_test, D_archive, D_release) + S

Размер S нельзя назначать «на глаз». Его следует вывести из записей о падении узлов, повторных запусках, перезагрузках и обязательной доступности релизного контура. Если таких данных нет, в документе закупки оставьте резерв как переменную и сначала проведите пилот.

Что измерять в течение пилота

Соберите одну и ту же версию проекта и зафиксируйте:

• чистую сборку после удаления Derived Data;
• инкрементальную сборку после изменения исходного файла;
• параллельные тесты на симуляторе;
• архивирование;
• подписание и подготовку публикации;
• восстановление после перезагрузки узла;
• повторный запуск после потери кэша.

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

Разделяйте три эффекта:

1. Ускорение одной задачи. Ожидание сокращается только у конкретной job.
2. Рост пропускной способности. Пул завершает больше задач за то же окно.
3. Сокращение очереди. Пользователь быстрее получает свободный узел.

Более мощный Mac может улучшить первый показатель, но не решить третий, если узел занят последовательным подписанием. В такой ситуации отдельный signing pool даст больший эффект, чем замена всех машин.

Общий пул сборки

В него направляйте обычные PR-сборки и задачи без чувствительных ключей. Для него важны быстрый checkout, воспроизводимая версия Xcode, очистка workspace и возможность временно добавить удалённые Mac.

Не смешивайте в этом пуле долгие регрессионные тесты с короткими проверками pull request. Иначе небольшое число тяжёлых job создаст очередь для всей команды.

Пул подписи

Архивирование, подпись и публикацию выделяйте в отдельный контур, если сертификаты или ключи нельзя безопасно выдавать всем Runner. Входом должны быть проверенный артефакт и явно разрешённая ветка, а не произвольный код из любого pull request.

Пул подписи должен иметь:

• ограниченный список репозиториев;
• отдельные секреты;
• очистку рабочего каталога после job;
• журнал выдачи и использования credentials;
• ручную или политическую блокировку публикации;
• проверенный сценарий отказа.

Эластичный пул

Эластичные Mac подходят для пиков PR, миграционных тестов и временного увеличения числа параллельных задач. Они не должны быть единственным местом хранения состояния, сертификатов или кэша.

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

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

Фиксированный пул, удалённые Mac или смешанная схема

Фиксированный пул оправдан, когда базовая нагрузка стабильна, окружение требует постоянного прогрева, а приватные зависимости сложны. Удалённые Mac удобны для коротких пиков, миграционных проверок и временного расширения без капитальной закупки. Смешанный пул обычно лучше защищает от двух крайностей: переплаты за простаивающее оборудование и длинной очереди в релизное окно.

Для предварительного пилота можно использовать планы Mac mini для корпоративного CI, но окончательное число узлов определяйте только после прогона собственного проекта, а не по названию конфигурации.

Используйте следующие ветвления при подготовке заявки:

• Если очередь возникает только в короткие окна, а средняя загрузка низкая — оставьте базовый фиксированный пул и добавьте эластичные Mac.
• Если очередь сохраняется весь рабочий период, а задания однородны — сначала сравните добавление узла с ускорением одной job; приоритет отдайте увеличению пропускной способности.
• Если CPU свободен, но растёт время тестов или архивирования — проверьте память, диск, симуляторы и параллельность job до покупки более мощного Mac.
• Если подпись блокирует остальные задачи — выделите signing pool, а не увеличивайте общий пул.
• Если удалённый узел не успевает получить окружение в пределах допустимого ожидания — исправьте bootstrap и кэш либо используйте постоянный узел.
• Если приватные зависимости недоступны извне — не считайте удалённую ёмкость рабочей, пока не подтверждены сеть, allowlist и восстановление после сбоя.
• Если стоимость определяется оплачиваемым временем Runner, сравните цену завершённой задачи, а не только цену часа. Правила биллинга и включённые объёмы проверяйте в документации по тарификации Actions Runner.
• Если организация приближается к системным ограничениям, сначала сверяйте их с официальной таблицей лимитов GitHub Actions, а затем планируйте расширение.

В закупочной модели используйте стоимость завершённой задачи или артефакта. Число Mac само по себе не показывает экономику.

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

Документация GitHub описывает модель оплаты Actions, но фактический TCO зависит от длительности job, повторных запусков и того, оплачивается ли подготовка среды. Считайте минимум три сценария: стабильная базовая нагрузка, кратковременный релизный пик и временный миграционный проект.

Покупка или аренда готова к расширению только после прогона реального workflow. Проверяйте не статус «узел онлайн», а весь путь от постановки job до получения артефакта.

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

Сколько Mac нужно корпоративной команде для CI на Xcode 27?

Фиксированного числа нет: потребность равна пиковому числу одновременно выполняемых задач с добавленным резервом на повторные запуски и изоляцию подписи. Сначала разделите PR-сборки, тесты, архивирование и релизные задания, затем измерьте очередь и длительность каждой группы. Число разработчиков используется только как косвенный источник прогнозов.

Как рассчитать параллелизм сборок iOS в CI?

Рассчитывайте его через поток задач и время обслуживания: для каждого типа задания зафиксируйте количество запусков в пиковом окне, среднюю и максимальную длительность, повторные попытки и допустимое ожидание. Получившийся спрос сравните с фактическим числом занятых Mac. Отдельно учитывайте задачи, которые нельзя выполнять параллельно из-за сертификатов или релизной блокировки.

Как расширять Mac-сборочные серверы по пиковой нагрузке?

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

Как планировать количество узлов Apple Silicon для CI?

Количество узлов Apple Silicon определяется не моделью процессора, а профилем задач и измеренной пропускной способностью одного узла. Проведите одинаковый набор чистых и инкрементальных сборок, тестов, архивов и подписаний. Затем умножьте требуемую пиковую ёмкость на коэффициент отказа и резерв, который вы подтвердили внутренними записями, а не взяли из рекламной спецификации.

Может ли удалённый Mac убрать очереди в CI для Xcode 27?

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

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

Перед запросом коммерческого предложения подготовьте четыре значения: базовую нагрузку, пиковый параллелизм, требования к signing pool и допустимое время подключения нового узла. Затем используйте KVMNODE для подбора удалённого Mac как вариант PoC, а решение о постоянном пуле принимайте только после описанной приёмки.