Типовые схемы сборки

Роль облачного Mac в процессе доставки

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

5 сценариев Сборка, доставка и эксперименты
1 выделенный узел Задачи выполняются по очереди
4 зоны ответственности Код, учётные данные, логи и артефакты разделены
ПАСПОРТ СБОРКИ iOS Release / Main
RUN-042
01
Коммит кода Событие в репозитории запускает задачу
Получено
02
Зависимости и кэш Восстановление по lock-файлу, фиксация попаданий в кэш
Готово
03
Xcode Archive Архивация на выделенном физическом узле
Выполняется
04
Проверка и передача Проверка подписи и экспорт контролируемых артефактов
Ожидает
Очередь задач MAIN → RELEASE → HOTFIX Для каждой задачи — отдельная рабочая папка
Проверка подписи Конфигурация совпадает Команда сама управляет конфиденциальными данными
Как использовать сценарии

Сначала определите ответственность, затем настройте автоматизацию

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

Воспроизводимая среда

Зафиксируйте версии Xcode и Command Line Tools, lock-файлы зависимостей и команды очистки. Перед сменой версий проверьте их в отдельной рабочей папке, а затем переключите очередь.

Версии и lock-файлы

Не храните учётные данные в репозитории

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

Минимальные права

Для артефактов определено место хранения

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

Контролируемый экспорт
Автоматическая сборка приложения

Пять этапов — от коммита до артефакта для проверки

Этот процесс подходит для регистрации CDNMac M4 как self-hosted runner: событие в репозитории запускает задачу, а готовый артефакт передаётся команде на проверку или в систему распространения.

01
Коммит кода Инициатор: разработчик или процесс слияния

Очередь запускается при изменении основной ветки или появлении релизного тега. Сначала задача фиксирует хеш коммита, ветку, инициатора и целевую схему Scheme, не выводя конфиденциальные переменные в лог.

Куда: изолированная рабочая папка на выделенном физическом узле
02
Восстановление зависимостей Инициатор: скрипт запуска

Восстановите Swift Package, CocoaPods и другие зависимости по lock-файлам. Ключ кэша должен учитывать как минимум хеш lock-файла и версию инструментов, чтобы старый кэш не загрязнял сборку после обновления.

Куда: версионируемая папка кэша и логи зависимостей
03
Xcode Archive Инициатор: задача сборки

Создайте архив, явно указав workspace, scheme, configuration и destination. При ошибке сохраните код выхода, важные записи лога и пакет результатов.

Куда: папка Archive с идентификатором коммита
04
Проверка подписи Инициатор: задача публикации

Проверьте Bundle Identifier, команду, срок действия сертификата и соответствие provisioning profile. Учётные записи разработчиков и ресурсы для подписи остаются под управлением команды пользователя.

Куда: контрольный список; без открытых учётных данных
05
Архивация артефактов Инициатор: скрипт передачи

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

Куда: контролируемое хранилище и очередь командной проверки
Очередь для нескольких веток

Один выделенный физический узел — три типа веток по правилам очереди

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

MAIN Непрерывная проверка

Основная ветка

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

Приоритет
Обычный
Рабочая папка
work/main
Очистка после выполнения
Удалить неотслеживаемые файлы
RELEASE Кандидат на выпуск

Релизная ветка

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

Приоритет
Высокий
Рабочая папка
work/release
Очистка после выполнения
Удалить временную связку ключей
HOTFIX Запуск после подтверждения

Ветка исправлений

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

Приоритет
После подтверждения
Рабочая папка
work/hotfix
Очистка после выполнения
Восстановить очередь и контрольную точку
Правила очереди

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

MAIN RELEASE HOTFIX CLEAN
FLUTTER ДЛЯ IOS

Разделяйте кроссплатформенные зависимости и этапы Xcode

В Flutter-сборке для iOS ожидание часто распределено между восстановлением зависимостей, CocoaPods и Xcode. Если разделить процесс на этапы, команде будет проще оценить пользу кэша и определить, на каком уровне произошёл сбой.

Границы этапов

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

  • Сначала проверьте совместимость версий Flutter SDK и проекта.
  • Добавьте хеш lock-файла в ключ кэша.
  • Очищайте кэши Pods и Dart независимо друг от друга.
  • Передавайте экспортированный пакет и файлы символов отдельно.
01
Восстановление зависимостей

Восстановите зависимости проекта и сохраните версию SDK и хеш lock-файла.

Кэш: папка пакетов Dart
02
CocoaPods

Установите нативные зависимости iOS согласно Podfile.lock; не используйте несовместимую папку Pods.

Лог: вывод установки Pods
03
Сборка в Xcode

Выполните Archive, явно указав workspace, scheme и configuration.

Артефакты: Archive и пакет результатов
04
Экспорт артефактов

После проверки подписи выполните экспорт и добавьте идентификатор коммита и контрольную сумму.

Куда: контролируемое хранилище команды

Попадание в кэш означает лишь, что соответствующие папку и ключ можно использовать повторно; оно не гарантирует ускорения всей сборки. После обновления Flutter, CocoaPods, Xcode или lock-файла заново проверьте границы кэширования.

ДОСТАВКА В TESTFLIGHT

Сначала команда проверяет артефакты, затем запускает распространение

Облачный Mac создаёт и проверяет артефакты сборки, но не заменяет согласование релиза командой. Учётные записи разработчиков, ресурсы подписи, сведения о версии и решение о распространении остаются под контролем пользователя.

  1. 01

    Создайте кандидат на выпуск

    Выполните Archive и экспорт из релизной ветки. Добавьте хеш коммита, версию, номер сборки, файлы символов и контрольную сумму.

  2. 02

    Проведите командную проверку

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

  3. 03

    Запустите распространение

    После проверки задача публикации под контролем команды выполняет загрузку с ограниченными правами. Не храните конфиденциальные данные в репозитории или обычных логах сборки.

  4. 04

    Зафиксируйте результат передачи

    Сохраните идентификатор артефакта, итог проверки и необходимые логи. После передачи удалите с узла временные экспортированные файлы и учётные данные.

Что делает узел CDNMac Сборка, архивация, проверка соответствия подписи и экспорт артефактов
Что делает команда пользователя Управление учётными записями и ресурсами подписи, согласование релиза, сведения для распространения и оценка соответствия требованиям
ЭКСПЕРИМЕНТЫ С ИИ НА APPLE SILICON

Проверяйте совместимость моделей, не обещая определённую производительность

CDNMac M4 оснащён M4, 16GB RAM и 256GB SSD. Узел подходит для проверки совместимости локальных моделей и создания прототипов, но сначала оцените требования модели, контекста, данных и памяти.

A

Подготовьте данные

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

Входные данные
Версионируемая выборка
Точка отката
Копия исходных данных только для чтения
B

Проверьте среду выполнения

Зафиксируйте версии macOS, среды выполнения, фреймворка и формата модели. Сначала проверьте загрузку, инференс и использование памяти на небольшой выборке, затем решайте, расширять ли эксперимент.

Проверка
Версии и запас памяти
Точка отката
Зафиксированный список зависимостей
C

Экспортируйте результаты

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

Результат
Параметры, сводка и логи
Ограничение
Без гарантий заданной производительности
Проверка конфигурации

Если модель, контекст и промежуточные данные не помещаются в 16GB RAM при стабильной работе или вам нужна не указанная конфигурация чипа и памяти, сначала уточните возможности у команды поддержки. Успешная проверка прототипа не подтверждает пригодность конфигурации для производственной нагрузки.

Уточнить конфигурацию для эксперимента
Формулировки для командного разбора

Опирайтесь на проверяемые инженерные факты

Ниже приведены примеры высказываний участников внутреннего разбора. Это не отзывы конкретных клиентов, оценки или рекомендации компаний.

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

Руководитель мобильной разработки

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

Инженер платформы CI

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

Независимый разработчик
Настройка рабочего процесса

Подготовка, переменные среды и точки отката при сбоях

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

Чек-лист для внедрения пяти типовых сценариев
Сценарий Что подготовить Переменные среды Точка отката при сбое
Автоматическая сборка приложения Доступ к репозиторию, версия Xcode, Scheme, lock-файлы зависимостей, настройки экспорта REPO_REF
BUILD_SCHEME
EXPORT_PATH
Сохраните пакет результатов и идентификатор коммита, удалите временную связку ключей и вернитесь к последнему коммиту, который успешно собирался
Сборка нескольких веток Приоритеты веток, отдельные рабочие папки, ограничение параллелизма, идемпотентный скрипт очистки BRANCH_NAME
RUN_PRIORITY
WORK_ROOT
Остановите следующие задачи в очереди, сохраните текущие логи, восстановите чистое рабочее дерево и исходный порядок очереди
Flutter для iOS Версия Flutter, Podfile.lock, workspace Xcode, правила формирования ключей кэша FLUTTER_ROOT
PODS_CACHE_KEY
IOS_SCHEME
Сбрасывайте кэш по этапам, сохраняйте пригодные для повторного использования логи и запускайте процесс заново с последнего успешно завершённого этапа
Доставка в TestFlight Согласование релиза, сведения о версии, соответствие подписи, проверка артефактов, контролируемые командой учётные данные RELEASE_VERSION
BUILD_NUMBER
ARTIFACT_PATH
Остановите задачу распространения, отзовите временные учётные данные, вернитесь к контрольному списку проверки и создайте новый кандидат на выпуск
Эксперименты с ИИ Формат модели, небольшая выборка данных, версия среды выполнения, контроль памяти и папка для экспорта MODEL_PATH
DATASET_PATH
RESULT_PATH
Сохраните список параметров и сводку результатов, восстановите зафиксированные зависимости и вернитесь к копии исходных данных только для чтения
01 Сначала выполните минимальную задачу

Оставьте один репозиторий, одну Scheme и одну цель экспорта, чтобы проверить полный цикл на узле.

02 Затем подключите конфиденциальные переменные

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

03 Расширяйте очередь в последнюю очередь

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

Перенесите типовой процесс на выделенный облачный Mac

Сначала выберите срок аренды и узел, затем по инструкции проверьте подключение, среду Xcode, права доступа к репозиторию и первую операцию Archive. Актуальный статус и сведения о доставке отображаются в консоли.