Сколько Mac нужно для параллельных сборок iOS в GitHub Actions в 2026 году? Оценка по размеру команды

У задания GitHub Actions доступны отметки времени queued_at и started_at: по ним можно отдельно измерить ожидание в очереди, а не путать его со временем самой сборки (описание полей заданий workflow в API). Вывод для планирования такой: универсального числа Mac для всех команд нет. Сначала соберите данные о совпадающих macOS-задачах, ожидании и времени занятости Runner, затем рассчитайте диапазон необходимой параллельности и проверьте его небольшим расширением пула.

Кому пригодится: небольшим iOS-командам, которые выясняют, действительно ли очередь оправдывает новые исполнительные узлы.
Также: командам с несколькими репозиториями, которым нужно распределить macOS CI, и платформенным специалистам, планирующим self-hosted Runner по наблюдаемой нагрузке.

Как оценить ёмкость GitHub Actions для параллельных сборок iOS

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

Полезно различать три величины:

• Частота запусков — сколько workflow запускается за выбранный период и в каких ситуациях: при push, pull request, по расписанию или вручную.
• Ожидание в очереди — промежуток от постановки задания до начала его выполнения.
• Занятость macOS Runner — время от старта задания до освобождения исполнителя, включая подготовку среды и завершающие операции.

Временные отметки заданий можно получить через API GitHub Actions и использовать для расчёта ожидания и длительности выполнения; соответствующие поля описаны в документации API workflow jobs. Для команды важно хранить эти значения по типам задач, а не сводить все запуски к единому среднему. Быстрый тест и полная сборка с публикацией по-разному занимают Runner и по-разному влияют на очередь.

Оценка потребности может быть записана без привязки к выдуманным нормативам:

Требуемые слоты в выбранный период ≈ число одновременно готовых macOS-заданий, которые команда хочет запускать без ожидания сверх установленной цели.

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

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

Для одного разработчика первый вопрос — не «сколько Runner купить», а повторяется ли ожидание в обычном рабочем цикле. Разовые совпадения возможны при серии отправок, повторном запуске после исправления теста или ручном запуске нескольких workflow. Если в остальное время задания стартуют без заметной задержки, постоянная дополнительная ёмкость может простаивать.

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

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

Для проверки причины полезны журналы и диагностика self-hosted Runner: официальное руководство по мониторингу и устранению проблем self-hosted Runner описывает, что проверять при неполадках исполнителей. Это важно, потому что медленный workflow сам по себе ещё не доказывает нехватку узлов.

Небольшая команда: определить допустимое ожидание

Для небольшой команды существенна не численность, а пересечение рабочих процессов. В одни часы могут совпасть отправки изменений, проверки pull request и подготовка выпуска; в другие macOS Runner простаивает. Зафиксируйте интервалы, когда задания действительно готовы исполняться, и определите, какое ожидание приемлемо для каждого вида задачи. Тестирование изменений и выпускной workflow могут иметь разные приоритеты, поэтому одна общая цель очереди не всегда подходит.

Наблюдаемая ситуация	Что измерять	Какое решение проверить
Короткие очереди при редких совпадениях запусков	Время ожидания и причина запуска	Сохранить текущий пул, проверить, можно ли перенести плановые задачи
Очередь повторяется в периоды совместной работы	Одновременные готовые задания и занятость Runner	Испытать ограниченное увеличение параллельных слотов
Ожидание велико, но исполнитель простаивает	Маршрутизацию, метки и доступность Runner	Исправить выбор исполнителя до добавления ёмкости
Тяжёлые сборки занимают Runner, лёгкие тесты ждут	Занятость по типу workflow и порядок зависимостей	Разделить очереди или изменить правила приоритета

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

При настройке workflow проверьте runs-on, метки и правила конкуренции. GitHub документирует синтаксис runs-on и concurrency в справочнике синтаксиса workflow. В частности, группа concurrency ограничивает одновременное исполнение: для группы допускается один выполняющийся запуск и один ожидающий, а новый ожидающий запуск может заменить предыдущий ожидающий запуск (правила concurrency). Поэтому очередь в такой группе не обязательно означает, что Mac Runner недостаточно: её могло создать намеренно заданное ограничение workflow.

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

Несколько репозиториев: спроектировать общий пул и маршрутизацию

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

Модель организации	Преимущества	Риски и условия проверки
Общий Runner-пул для репозиториев	Задания могут использовать общую доступную ёмкость	Проверьте доступ репозиториев, метки и влияние тяжёлых задач на остальные проекты
Отдельные пулы по проектам	Проще задать границы доступа и требования конкретного проекта	Ёмкость может простаивать отдельно от очереди в другом проекте
Смешанная маршрутизация	Общие задачи распределяются вместе, особые workflow направляются отдельно	Нужны согласованные метки и правила, иначе задания будут ждать неподходящий Runner

Группы Runner позволяют организовывать исполнителей и управлять тем, какие репозитории и workflow могут их использовать. Перед разделением проверьте актуальные правила в официальном описании групп Runner. Для self-hosted исполнителей также важно понимать, как назначаются метки и как workflow выбирает подходящий Runner; эти механизмы описаны в документации по self-hosted Runner и настройке self-hosted Runner.

Как распределить macOS CI между несколькими репозиториями? Сначала сгруппируйте задания по требованиям: тесты, полные сборки, выпускные операции и задачи с особым доступом. Затем определите, какие из них могут делить общий пул, а какие должны иметь отдельную маршрутизацию. Решение следует проверять по фактическим очередям и доступности Runner, а не только по числу репозиториев.

Не смешивайте ограничения GitHub Actions с собственными оценками ёмкости. Правила платформы для групп, выбора Runner и конкуренции нужно сверять с документацией; расчёт нужных слотов по журналам — это планировочная оценка, а не обещание платформы о конкретном времени старта. Не следует также выводить число macOS Runner из лимитов, которые относятся к другой части workflow или зависят от настроек организации.

Пять шагов для расчёта и пробного расширения

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

Шаг первый: соберите данные по каждому типу задания.
Записывайте время постановки в очередь, начало и завершение, репозиторий, ветку, тип запуска и выбранные метки Runner. Используйте API или историю workflow, а затем сводите данные в таблицу, где тесты не смешаны с полными сборками и публикацией.

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

Шаг третий: задайте приемлемое ожидание по типам работ.
Зафиксируйте, какое ожидание допустимо для проверки pull request, плановой сборки и выпуска. Не подменяйте критерий одним усреднённым показателем: релизный процесс может требовать более предсказуемого старта, чем необязательная проверка.

Шаг четвёртый: проверьте настройки маршрутизации и сериализации.
Сопоставьте runs-on с доступными метками Runner, проверьте членство репозиториев в нужных группах и условия concurrency. Дополнительно просмотрите зависимости jobs: если macOS-задача ждёт предыдущий этап, который не может выполняться параллельно, свободный исполнитель не устранит эту задержку.

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

Показатель до и после изменения	Что он помогает определить	Как трактовать без ложного вывода
Время в очереди по типам workflow	Изменилось ли ожидание нужных задач	Сравнивать сопоставимые периоды и типы запусков
Одновременная занятость Runner	Использовались ли добавленные слоты	Простой может быть нормальным, если ёмкость нужна только в пиковые периоды
Ошибки и повторные запуски	Не ухудшилась ли стабильность исполнения	Проверять причины ошибок, а не считать их только следствием нагрузки
Доля заданий, ожидающих неподходящий Runner	Корректно ли работают метки и группы	При ошибке маршрутизации новые узлы могут не попасть в нужный пул

Проверить, что именно тормозит сборку

Как понять, проблема в количестве Runner или в шагах сборки? Сопоставьте время ожидания с моментом старта. Если задание долго не начинается, когда подходящие Runner заняты, нехватка свободных слотов возможна. Если Runner доступен, но job продолжает ждать, проверьте метки, группы и зависимости. Если job стартует быстро, а затем долго выполняется, анализируйте сами шаги: подготовку зависимостей, тесты, компиляцию, работу с кешем и завершающие операции.

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

Оценка параллельности не заменяет проверку стабильности. Дополнительные Runner не исправят неисправную среду, несовместимые метки или workflow, который ожидает предыдущий job. Для self-hosted конфигурации держите под рукой официальные инструкции по настройке Runner: они помогают сверить требования выбора и исполнения с фактической конфигурацией узлов.

Чек-лист перед изменением размера пула

• [ ] Для каждого macOS workflow записаны постановка в очередь, начало и завершение.
• [ ] Отдельно выделены тесты, полные сборки и выпускные задачи.
• [ ] Очередь повторяется в обычных рабочих циклах, а не только в единичном всплеске.
• [ ] Целевое ожидание сформулировано для нужных типов задач.
• [ ] Проверены runs-on, метки, доступ к группам Runner и условия concurrency.
• [ ] Задания, которые могут ждать зависимости, не приняты за нехватку свободного Mac.
• [ ] До расширения определены показатели сравнения: очередь, занятость, ошибки и повторные запуски.
• [ ] После пробного изменения принято решение по результатам сопоставимых наблюдений, а не по впечатлению от одного запуска.

Стоимость запросов к модели и расходы на CI — разные статьи. Даже если workflow использует AI-инструменты, объём их API-вызовов не показывает, сколько времени macOS Runner занят сборкой. В оценке пула учитывайте использование и аренду исполнительной инфраструктуры отдельно от API, лицензий и других внешних услуг; не складывайте их в одну оценку «стоимости параллельной сборки».

Если собственная машина уже доступна, а нагрузка регулярна и предсказуема, её можно рассматривать как постоянное решение — при условии, что команда готова обслуживать среду, обеспечивать доступ и поддерживать доступность исполнителя. Если нагрузка нестабильна или нужно проверить расчёт перед покупкой оборудования, аренда Mac mini для сборок позволяет оценить удалённый вариант; перед этим стоит сверить доступные условия и порядок подключения на странице удалённой аренды Mac mini. Аренда Zutcloud уместна, когда требуется временная macOS-ёмкость для испытания очереди или ограниченного проекта, но не заменяет собственную инфраструктуру при постоянной предсказуемой нагрузке и не подходит, если задаче необходим физический интерфейс, недоступный удалённо. Начните с данных Actions, а затем сопоставьте рассчитанную потребность с подтверждёнными условиями аренды — без назначения числа узлов по размеру команды или предположений о производительности.

Читать также

• Как выбрать CI/CD для iOS-команды и организовать удалённые сборки на Mac
• Облачные узлы M4: ускорение сборок и параллельные этапы CI
• Как подобрать Mac для Xcode, контейнеров и смешанных нагрузок разработки