Компиляция и сборка на облачном узле M4: мы перенесли конвейер

Основная модель Vuncloud — Mac mini M4. Для таких проектов, как наш, где нужно и запускать Xcode, и периодически работать с Docker и скриптами, разница в производительности CPU и памяти напрямую сказывается на том, «ждёшь компиляции» или «продолжаешь писать код». После переноса полной сборки старого проекта на узел M4 время чистой компиляции сократилось примерно вдвое — и дело не только в сэкономленных минутах, но и в сохранении потока работы, что особенно заметно при работе через удалённый рабочий стол.

Для каких сценариев сборки подходит облачный Mac?

Перед миграцией мы систематизировали типичные сценарии по степени проблемности:

От «компилируется» до «можно смело переносить основную работу в облако»

Мы больше не воспринимаем облачный Mac лишь как удалённый монитор. Когда время чистой сборки заметно сократилось, команда стала выносить больше проверок в одну и ту же фиксированную среду: юнит-тесты, статический анализ и проверка подписи артефактов теперь выполняются параллельно с дизайн-ревью, что сокращает издержки на коммуникацию по сценарию «у меня проходит, у коллеги — нет».

На Apple Silicon линкер и компилятор Swift более чувствительны к пропускной способности памяти. Если в проекте много Swift Package, смешанных модулей или крупных Asset Catalog, рекомендуется выделить в облаке немного больше памяти, чем обычно требуется на локальной машине, — чтобы пики компиляции не задействовали swap и не свели на нет с трудом достигнутое преимущество CPU. Мы внутренне прогоняем одни и те же проекты на разных узлах по несколько раз, фиксируя медианное wall time и хвостовые задержки.

Три кита кэширования: DerivedData · CocoaPods · SPM

Кэш — это самый прямой рычаг влияния на скорость сборки. Следующие три директории рекомендуется включить в базовый образ и пометить версионными метками:

~/Library/Developer/Xcode/DerivedData/   # Кэш инкрементальной компиляции Xcode
~/Library/Caches/CocoaPods/              # Кэш загрузок CocoaPods
~/.spm-cache/ (или ~/.swiftpm/)           # Кэш Swift Package Manager

# В ежедневных итерациях синхронизируем только дельту, нужную для текущей сессии
# Настоящий холодный старт откладываем до мажорного обновления образа

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

Мониторинг, откат и «кто возьмёт трубку в три часа ночи»

Перенос сборки в облако — это не только про экономию нескольких минут wall time, но и про то, можно ли быстро локализовать проблему при сбое. Мы разделили типичные инциденты на четыре категории, для каждой из которых отдельно описаны пороги оповещений и дежурные инструкции:

• Расхождение образа— версия Xcode или CLT обновилась без уведомления
• Тайм-аут разрешения зависимостей— тайм-аут при получении удалённых данных SPM / CocoaPods
• Истёкший сертификат подписи— истёк дистрибутивный сертификат или Provisioning Profile
• Недоступность удалённого Git— медленное разрешение DNS для субмодулей ошибочно воспринимается как медленная компиляция

Если ваша команда распределена по нескольким географическим регионам, рекомендуется автоматически синхронизировать «хэш артефакта последней успешной ночной сборки» и «фрагмент лога сбоя» в канал только для чтения — это сократит утренние издержки на взаимное информирование. Так даже если кто-то в отпуске, найдётся тот, кто сможет определить: проблема в окружении или регрессия в коде.

В стратегии отката не ограничивайтесь резервным копированием всего диска — держите компактный образ с «последней рабочей комбинацией Xcode + CLT + CocoaPods»: он легче и восстанавливается быстрее, чем полный домашний каталог пользователя. Кроме того, в конвейере ночной сборки вынесите «время получения субмодулей» в отдельную метрику: отделив время DNS и рукопожатия Git от фазы компиляции, вы легче определите — нужно ли менять конфигурацию resolver или зеркалировать субмодули во внутреннюю сеть. Как только эти метрики образуют трендовый график, сопоставив их с загрузкой CPU на узле M4, станет понятно: добавлять машины или чинить сеть.