По состоянию на 7 августа 2026 года Apple опубликовала системные требования и заметки к Xcode 27, но официальных характеристик Mac Mini M5 ещё нет — это подтверждает необходимость проектировать CI по нагрузке, а не по слухам о чипе (требования Apple к Xcode).

Симптом: сборки периодически ждут в очереди, а тесты, подпись и релиз начинают конкурировать за один исполнитель.

Быстрое решение: при низкой и сериализуемой нагрузке оставьте один Mac; при параллельных тестах, нескольких проектах или требованиях к изоляции сразу закладывайте несколько узлов. До выхода Mac Mini M5 проверьте это на временно подключаемых Mac и сравните реальные очереди.

Эта статья предназначена для небольшой App-команды, у которой уже появляются задержки и вопрос о второй Mac-машине; для iOS DevOps-руководителя, которому нужно разделить тестирование и публикацию; для платформенной команды, расширяющей общий Mac в эластичный пул исполнителей.

Сначала зафиксируйте границы решения

В обсуждениях Mac Mini M5 легко перепутать подтверждённые сведения с прогнозами. На указанную дату Apple не подтвердила название продукта, чиповую комбинацию, цену, дату выхода или набор конфигураций Mac Mini M5. Сообщения о тестировании вариантов M5 Pro или M6 можно использовать только как фон для планирования места, сетевых профилей и будущего выбора узлов, но не как основание для расчёта производительности.

Xcode 27 уже имеет опубликованные системные требования, а его release notes показывают, что при планировании необходимо учитывать не только компиляцию, но и совместимость инструментов, SDK и окружения (заметки к выпуску Xcode 27). Поэтому вопрос «один Mac Mini M5 или несколько?» сейчас следует формулировать иначе: сколько независимых задач должны выполняться одновременно, какие из них нельзя запускать рядом и сколько времени команда готова терпеть очередь.

У вас есть три базовые архитектуры:

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

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

Первый шаг: проверьте, выдерживает ли один Mac низкую нагрузку

Для индивидуального разработчика и микрокоманды число участников само по себе ничего не решает. Важнее три наблюдения:

  1. сколько минут задание находится в очереди до старта;
  2. как часто два или более задания перекрываются по времени;
  3. сколько часов в неделю уходит на ручное обслуживание исполнителя.

Если сборка запускается после коммита, ночью или по расписанию, а редкие ветки не создают одновременный поток, один Mac Mini M5 — если его характеристики после анонса окажутся подходящими — может быть достаточным. Не нужно заранее строить пул ради гипотетического пика, который возникает раз в месяц.

Но одиночный узел имеет скрытые ограничения:

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

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

Можно ли нескольким iOS-проектам использовать один Mac?

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

Разделите как минимум:

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

Один общий исполнитель подходит, когда проекты в основном проходят короткую валидацию и имеют согласованный набор SDK. Он становится рискованным, когда один продукт требует отдельной версии Xcode, другой — нестандартных скриптов, а третий хранит доступ к публикации в App Store Connect. В таком случае второй узел нужен прежде всего для изоляции, а не для ускорения.

Второй шаг: отделите обычную сборку от выпуска

У небольшой мобильной команды нагрузка резко меняется в день релиза. На одном Mac одновременно могут встретиться:

  • проверка pull request;
  • сборка release candidate;
  • UI-тесты;
  • архивирование;
  • подписание;
  • загрузка артефакта;
  • повторный запуск после исправления теста.

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

Минимальное разделение выглядит так:

  • универсальный узел сборки — pull request, обычные архивы, линтеры и незащищённые тесты;
  • контролируемый узел выпуска — архивирование релизной версии, подпись и доставка;
  • дополнительный тестовый узел — только если автоматические тесты регулярно перекрываются с обычными сборками.

Apple отдельно описывает сертификаты как объект управления с определённым назначением и жизненным циклом (обзор сертификатов Apple). В документации по распространению приложения также разделены операции подготовки и доставки подписанного продукта (руководство Apple по распространению на зарегистрированные устройства). Это практический аргумент в пользу разных ролей узлов: доступ к сертификату не должен зависеть от того, свободен ли сейчас обычный исполнитель.

Второй узел не обязателен, если:

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

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

Важно: свободные CPU и память не делают совместный запуск безопасным. Задание подписи следует отделять из-за уровня доступа и аудита, даже если в этот момент Mac почти простаивает.

Третий шаг: отличите нехватку мощности от тестового пика

Команды качества часто первыми сталкиваются с вопросом о нескольких узлах. Параллельные симуляторы, UI-тесты и повторный запуск после сбоя создают кратковременный пик, который средняя дневная загрузка скрывает.

В этом сценарии есть два пути:

  • ускорить одну задачу — сократить подготовку, убрать лишние UI-сценарии, улучшить кэширование;
  • увеличить параллельность — направить независимые задания на несколько исполнителей.

Не выбирайте второй путь только потому, что тесты «долго идут». Сначала разложите очередь по причинам:

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

Apple документирует механизм параллельного выполнения тестов, но сама возможность распараллеливания не означает, что каждый проект получит линейное ускорение (документация Apple по параллелизации тестов). Проверьте, сколько заданий действительно выполняются одновременно, сколько минут они стоят в очереди и какая доля повторных запусков вызвана инфраструктурой, а не кодом.

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

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

Запишите для каждой задачи:

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

Так вы увидите, требуется ли ещё один Mac, отдельный тестовый исполнитель или пересмотр сценариев.

Четвёртый шаг: разделите среду для нескольких проектов

Платформенная команда обычно думает о производительности, но основной выигрыш от нескольких Mac часто связан с уменьшением радиуса отказа. Один общий узел связывает между собой версии Xcode, Ruby, Swift Package Manager, CocoaPods, сторонние инструменты и локальные настройки.

Для каждого проекта определите:

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

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

Плюсы такой схемы:

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

Минусы:

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

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

Подходы к расчёту ёмкости можно дополнить материалом о метриках очереди и вместимости Xcode CI, а перед подключением удалённого исполнителя проверить его по критериям приёмки Mac-среды.

Пятый шаг: изолируйте подпись, секреты и публикацию

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

Проверьте четыре уровня:

  1. Сертификаты. Какие типы сертификатов требуются проекту и кому разрешено их обновлять?
  2. Закрытые ключи. Где они хранятся, как ограничен доступ и как фиксируется использование?
  3. Учётные записи. Может ли обычный pull request вызвать операцию публикации?
  4. Аудит. Можно ли восстановить, какой pipeline, коммит и оператор использовали ключ?

Apple описывает создание подписанного кода и связанные с этим требования для распространения (документация Apple о подписанном коде). Для iOS-команды это означает, что разделение «тесты — подпись — публикация» должно быть отражено не только в названиях pipeline, но и в правах узлов.

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

Шестой шаг: выберите архитектуру по наблюдаемым условиям

Ниже — рабочий инструмент выбора. Он не предполагает, что характеристики ещё не анонсированного Mac Mini M5 уже известны.

Вариант Когда выбирать Что измерить заранее Главный недостаток
Один Mac Низкая частота заданий, почти нет перекрытий, один доверенный проект Максимальное ожидание, ручное обслуживание, простои при обновлении Единая точка отказа и общий конфликт окружений
Фиксированные несколько узлов Регулярные параллельные сборки, разные проекты, раздельная подпись Долю пересечений, сбои по окружению, время восстановления узла Постоянные затраты на обслуживание
Эластичный пул Релизные пики, массовые тесты, меняющаяся команда Пиковую очередь, длительность подключения, стабильность удалённого доступа Нужно управлять выдачей, возвратом и чистотой временных узлов

Для Xcode 27 CI используйте следующие условия:

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

Седьмой шаг: протестируйте схему до выхода Mac Mini M5

До официального анонса не переносите на будущий Mac Mini M5 характеристики MacBook Pro с M5 Pro и не используйте медийные прогнозы как расчёт ёмкости. Сначала создайте воспроизводимый тест архитектуры.

  1. Выгрузите за рабочую неделю события CI: постановка, старт, завершение и повтор.
  2. Разделите задания на обычную сборку, тесты, архивирование и публикацию.
  3. Отметьте пары задач, которые регулярно выполняются одновременно.
  4. Запустите тот же набор на одном удалённом Mac.
  5. Добавьте второй временный узел только на периоды перекрытия.
  6. Сравните максимальное ожидание, число повторов и время ручного вмешательства.
  7. Проверьте отказ одного исполнителя и восстановление очереди.
  8. Отдельно подтвердите, что тестовый pipeline не получает доступ к ключам публикации.
  9. После появления официальных данных Apple сопоставьте реальные конфигурации с этой моделью нагрузки.
  10. Пересчитайте решение, если фактическая память, порты, накопитель или доступные варианты Mac Mini окажутся иными, чем предполагалось.

Для удалённой команды дополнительно проверьте:

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

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

Итог для трёх типов команд

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

Фиксированные несколько узлов выбирайте для команды с ежедневными проверками, несколькими проектами, отдельным релизным процессом и постоянной конкуренцией за исполнителя. Здесь важны изоляция и уменьшение радиуса отказа.

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

Если текущая схема — один общий локальный Mac, у неё есть три реальных минуса: очередь блокирует все проекты, отказ останавливает весь CI, а ключи подписи сложнее отделить от тестовых задач. Покупка нескольких машин сразу решает часть этих проблем, но добавляет капитальные затраты, обслуживание и необходимость заранее угадать конфигурацию ещё не анонсированного Mac Mini M5.

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

Читать также

Удалённый узел kvmsync M4

Масштабируйте CI для iOS с kvmsync

Арендуйте удалённый Mac в kvmsync для сборки, тестирования и подписи приложений без покупки собственного оборудования.

Арендовать Mac mini M4 Сравнить тарифы M4