Buildkite 2026: macOS-агенты на посуточном облачном Mac | Всплески, артефакты, SLO очереди

Buildkite раскрывается лучше всего, когда парк агентов ваш: глубина очереди, секреты и раскладка диска остаются под контролем, а плоскость управления планирует шаги. Apple Silicon — не «всплывающие» Linux-ВМ: архивы Xcode и нотаризация хотят предсказуемых ядер и быстрого локального NVMe, а CapEx на круглосуточные Mac mini бьётся с релизными поездами, где пик нагрузки две недели в квартал. Аренда облачного Mac посуточно даёт третью позу: оставьте один небольшой постоянный агент для «гигиенических» сборок и подключайте дополнительные macOS-агенты только когда всплеск merge или дедлайн App Store это требует. Ниже — цифры, которые можно защитить на планёрке: эластичность, где хранить артефакты и как формулировать SLO очередей так, чтобы их не срезал финансовый блок.

p95

Целевое ожидание в очереди (на пайплайн)

30–90 дн.

Типичное окно хранения артефактов Buildkite

2×

Запас burst-агентов к медианному steady

Топология, теги агентов и зачем посуточный Mac сочетается с очередями Buildkite

Каждый арендованный Mac регистрируйте отдельным агентом с явными тегами (например queue=ios, capacity=burst). Срочные пайплайны направляйте в очередь, которую обслуживают и постоянные, и burst-агенты, а длинные интеграционные сьюиты держите в стабильном пуле — иначе переработанные хосты оборвут уже идущую работу. Посуточный облачный Mac хорошо стыкуется с Buildkite, потому что жизненный цикл явный: подняли агент с зафиксированным токеном, «осушили» нужный срез сборок, вывели машину из эксплуатации. В runbook стоит вынести стабильность hostname, pin версии buildkite-agent и расположение DerivedData — иначе при пиках вы отлаживаете холодный кэш, а не реальную нехватку ёмкости. Быстрый чеклист по регистрации runner и токенам в коротком цикле: Короткий цикл CI в 2026: всплеск сборок и новый облачный Mac — регистрация Runner, сеть и минимальные токены за 30–60 минут (чеклист и FAQ).

Эластичность при всплесках: когда лишние агенты выигрывают у «широкого» hosted-пула

Эластичность — это скорость, с которой простаивающая ёмкость превращается в выполняемые джобы без правок YAML. У hosted-пулов прогрев спрятан за очередью вендора — пока не упрётесь во вторник после обеда, когда все iOS-команды дергают одни и те же ресурсы. Self-hosted Buildkite плюс burst облачного Mac переносит прогрев на ваш календарь: финансы видят посуточную аренду вместо внезапного закупа железа. Окупаемость burst измеряйте медианой времени в очереди, p95 и повторами, списанными на дрейф среды. Если p95 нарушает SLO только в предсказуемых окнах, burst-агенты чаще выигрывают у стоек, которые простаивают одиннадцать месяцев в году.

FAQ: может ли один агент Buildkite выполнять несколько джоб параллельно?

Каждый процесс агента привязан к одной джобе за раз. Параллелизм даёт несколько агентов или несколько машин. Планируйте burst как дополнительные регистрации агентов, а не как один «мега-агент», если только вы намеренно не сериализуете работу.

Артефакты: хранилище Buildkite против S3-совместимого object storage

Артефакты Buildkite удобны для логов и умеренных бинарников; крупные .xcarchive или деревья dSYM лучше грузить в версионируемое object storage с политиками жизненного цикла, которые может аудировать security. В Buildkite оставляйте лёгкие манифесты, чтобы повторные прогоны знали, какой object key подтянуть. Если облачные Mac перерабатываются ежедневно, считайте локальный диск эфемерным: загрузка должна завершиться до выхода из шага. Про компромисс между удалённым кэшем и локальным диском узла в коротком цикле см. Короткий цикл облачного Mac CI в 2026: удалённый кэш сборки против локального диска узла.

Пример: отдельный шаг выгрузки (концептуально)

# После успешных тестов вынесите тяжёлые бинарники «в сторону»
steps:
  - label: ":package: Архив в object storage"
    agents:
      queue: "ios"
    commands:
      - ./scripts/upload_release.sh --bucket "$RELEASE_BUCKET" --build "$BUILDKITE_BUILD_NUMBER"

Напоминание по compliance

Если в артефактах есть символы или данные клиентов, сопоставьте срок хранения с политикой DLP до включения длинного retention в Buildkite — в аудите чаще проще доказать бакет-политики в object storage, чем бесконечно растущий индекс артефактов.

Матрица решений по SLO очередей

Используйте таблицу как основу разговора между платформенной командой и продуктом: выберите строку под релизный ритм, затем согласуйте число агентов и стратегию артефактов с нужным столбцом. Если две команды делят одну очередь, разделите SLO: продукту важен p95 времени до первой macOS-джобы, security — неизменяемость артефактов через N часов после merge.

Релизный паттерн	Позиция по SLO очереди	Позиция по артефактам
Непрерывный trunk, много мелких PR	Базовый always-on + автоподъём burst Mac при p95 очереди > 5 мин	Короткий retention в Buildkite; символы в холодном хранилище 90 дн.
Ежемесячный поезд с жёстким RC-freeze	Прогрев burst-пула за 48 ч до freeze; заморозка тегов очереди	Неизменяемые RC-бандлы в object storage; в Buildkite только манифесты
Редкие выкладки в App Store	Минимальный always-on; посуточный Mac только на неделю подписи	Логи нотаризации в Buildkite 30 дн.; копии IPA версионируются снаружи
Мультирепо / монорепо	Отдельная очередь на семейство репозиториев, без head-of-line blocking	Шардирование кэшей по очередям; без одного гигантского каталога артефактов

Совет по наблюдаемости

Экспортируйте время ожидания в очереди из API Buildkite на тот же дашборд, что и длительность git fetch. Команды, которые смотрят только на длительность шага, часто недооценивают пул Mac, когда реальное узкое место — блокировка на общем томе кэша.

Операционный FAQ: токены, drain и передача релиза

Ротируйте токены агентов через секреты CI; у burst-хостов — ограниченные токены только на те очереди, которые они усиливают. Перед выключением посуточного Mac выполните корректный drain, затем снимите регистрацию агента, чтобы метрики очереди оставались честными. Менеджерам релиза дайте одну ссылку: сборка Buildkite, хэш манифеста и префикс в object storage.