Как оценить, сколько Mac-сборщиков нужно для CI/CD команды iOS? Планирование мощности на 2026 год

Документация Apple описывает в CI-процессе Xcode такие действия, как сборка, тестирование и архивирование приложения (справочник рабочих процессов Xcode Cloud). Поэтому оценивать инфраструктуру нужно не по числу разработчиков, а по тому, сколько задач приходит одновременно, сколько они занимают и какое ожидание допустимо. Сначала измерьте нагрузку, затем проверьте расчёт на характерных сборках; устойчивую базовую потребность рассматривайте как постоянную ёмкость, а редкие пики — как возможный повод для эластичного дополнения.

Подходит: техническим руководителям и CI/CD-инженерам, которым нужно планировать мощность команды iOS на основе журналов и тестов.

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

Исходная точка: журналы сборок и очередей

Начните не с покупки оборудования, а с выгрузки истории CI. Для каждой задачи вам нужны как минимум время поступления, время фактического старта, время завершения, тип работы, результат и сведения о повторных запусках. Разница между постановкой в очередь и стартом показывает ожидание; промежуток от старта до завершения — фактическое время занятия runner. Смешивать эти значения нельзя: длинное выполнение и длинная очередь требуют разных мер.

Разделите поток на классы, которые отражают пользовательский и операционный смысл: быстрые проверки изменений, сборки основной ветки, тестирование, анализ и архивирование. Рабочие процессы Xcode включают разные действия, и их нагрузка не обязана быть одинаковой: описание действий Xcode Cloud и руководство Apple по сборке Swift-пакетов в CI помогают увидеть, почему тип задачи следует фиксировать отдельно.

В журнале также отмечайте ветку или событие, runner-метку либо группу, итоговый статус и повтор после ошибки. Не удаляйте неудачные запуски из анализа: повторы занимают ресурсы и могут усиливать очередь именно тогда, когда команда уже разбирает проблему. Если текущая система не сохраняет время ожидания, сопоставьте время создания job с фактическим началом исполнения по доступным событиям; зафиксируйте ограничения такого восстановления.

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

Важно. Не переносите секреты, содержимое ключей подписи и ненужные персональные данные в выгрузку для анализа. Проверьте, кому доступны журналы и тестовые артефакты; вопросы хранения и разделения данных на удалённых Mac стоит сверить с описанием конфиденциальности SDKMac.

Оценка параллельности и допустимого ожидания

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

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

Сопоставьте приход задач и их длительность с фактическим перекрытием. Спросите себя: сколько задач одновременно ожидают выполнения в пиковый момент; какие из них действительно должны запускаться сразу; есть ли зависимость, которая задерживает весь поток; сколько повторов создают неудачные проверки? Полученное число параллельных работ — рабочая гипотеза, не окончательное количество Mac. Её ещё предстоит проверить на реальных runner и учесть ограничения планировщика.

Важно различать очередь, вызванную недостатком ёмкости, и очередь, созданную конфигурацией. Если job назначен на определённую метку, но доступная машина не совпадает с ней, добавление другого runner не поможет. Аналогично, глобальное ограничение параллельности в CI может удерживать задачи, хотя свободный Mac уже есть. Сначала проверьте маршрутизацию и лимиты, иначе вы оплатите дополнительную мощность, которая не участвует в работе.

Сопоставление задач и Mac runner

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

Если вы используете GitHub Actions, его документация позволяет отдельно разобраться в управлении самостоятельно размещёнными runner и настройках синтаксиса workflow, включая матричные стратегии и параллельное выполнение. Это пример конкретной платформы, а не общая инструкция для всех CI-систем: названия параметров, правила назначения и лимиты планировщика у других платформ могут отличаться. Сверяйте фактическую версию документации с конфигурацией вашего проекта.

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

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

Сравнение вариантов ёмкости

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

Чтобы превратить сравнение в решение, пройдите условия по порядку и зафиксируйте основание выбора:

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

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

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

Проверка гипотезы на представительных задачах

Пилот должен проверить не идеальный короткий build, а набор задач, который отражает повседневную работу: характерную проверку изменений, тестовый запуск и сборку, требующую архивирования, если она входит в ваш процесс. Документация Apple описывает действия и контекст Xcode CI, включая первичную настройку workflow; конкретный набор в тесте выбирайте по собственным запускам, а не копируйте из чужого проекта.

Зафиксируйте исходное состояние: текущую очередь, длительность, ошибки и повторные запуски. Затем выполните тот же сценарий с предполагаемым изменением — например, выделенным runner или дополнительным пулом. Сравнивайте одинаковые типы задач и сопоставимые конфигурации; если одновременно обновить зависимости, перестроить workflow и добавить машину, будет трудно понять, что именно улучшило результат.

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

Для конкретной платформы проверьте фактические лимиты параллельного исполнения и поведение назначений runner. В GitHub Actions доступные настройки workflow задаются правилами платформы, поэтому справочник синтаксиса следует читать применительно к вашей конфигурации, а не использовать как источник универсального количества Mac. При изменении конфигурации runner повторно проверьте разрешения и группы: параллельная задача должна иметь допустимый маршрут к нужной машине.

Если тест показал, что дополнительная ёмкость не меняет ожидание, сначала ищите другое ограничение: лимит CI, неверную метку, последовательный шаг в workflow, медленный тестовый стенд или повторяющиеся сбои. Если очередь сократилась, но длительность выполнения выросла, проверьте конкуренцию и сопоставьте итоговое время завершения всего потока с целью команды. Добавлять машины следует после объяснения результата, а не только потому, что в отчёте одновременно видны занятые runner.

FAQ: вопросы при планировании

Разработчики как показатель нагрузки

Численность команды может пригодиться как контекст для прогноза роста, но не заменяет измерение активности CI. У разработчиков различаются частота отправки изменений, привычки запуска тестов, используемые ветки и доля автоматических проверок. Сопоставляйте кадровый план с историей поступления job: рост команды — сигнал пересмотреть наблюдения, а не основание автоматически добавить машину.

Очередь и решение об увеличении ёмкости

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

Полезные поля истории CI

Записывайте момент создания job, начало выполнения, завершение, класс задачи и итоговый статус. Добавьте сведения о повторе, ветке и назначенном runner, если их можно получить. Такие данные позволяют отличить длинное ожидание от медленного выполнения, а нехватку машин — от неверной маршрутизации. Если часть полей отсутствует, отметьте это: неполный журнал не даёт основания для точного прогноза.

Разделение пиков и постоянной нагрузки

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

Пересмотр мощности и закупочного решения

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

Для каждого пересмотра сохраняйте исходные данные, принятые цели и результат теста. Укажите, что изменилось с прошлого сравнения: ограничения CI, runner-группы, доступы, длительность сборки, цены поставщика или срок аренды. В GitHub Actions настройки self-hosted runner и workflow описаны отдельно; сверяйте применяемые правила с официальной документацией по runner, а не переносите их на другую платформу.

В итоге решение должно отвечать на несколько практических вопросов: какие задачи обязаны стартовать без задержки; какую очередь команда принимает для остальных; какая часть нагрузки повторяется; можно ли вынести пик на дополнительный Mac; что произойдёт при недоступности такого ресурса. Ответы превращают запрос «сколько машин купить» в проверяемое требование к пропускной способности и условиям эксплуатации.

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

Часто задаваемые вопросы