Четыре команды — четыре конвейера

1. Отправьте код

   Разрабатывайте на Windows и отправляйте проверенный коммит в репозиторий. Файл блокировки зависимостей храните вместе с кодом, чтобы на удалённом сервере не установился другой набор зависимостей.

2. Соберите архив

   Узел в Токио забирает код, устанавливает зависимости проекта и запускает flutter build ipaСертификаты подписи, профили provisioning и права доступа к ним настраиваете вы.

3. Загрузите для распространения

   Проверьте версии приложения и сборки, затем с помощью fastlane pilot загрузите сборку в TestFlight. Сохраните IPA, журналы и идентификатор соответствующего коммита в собственном хранилище артефактов.

Для распространения через TestFlight вам по-прежнему понадобятся действующая учётная запись разработчика, материалы для подписи и ключ API App Store Connect. Удалённый сервер их не заменяет.

1. Подключите runner

   Установите GitHub Actions self-hosted runner на узле в Сингапуре. Направляйте задания macOS на этот узел с помощью меток и ограничьте список репозиториев и веток, из которых можно запускать задачи.

2. Разделите задачи по приоритету

   main запускайте сборку и базовые проверки при слиянии в main; для ветки релиза оставьте отдельные задачи;nightly отведите на длительные UI-тесты в симуляторе.

3. Изолируйте рабочие каталоги

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

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

1. Проверьте совместимость

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

2. Зафиксируйте входные данные для оценки

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

3. Сохраните результаты эксперимента

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

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

1. Передача файлов и пробная проверка

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

2. Организуйте очередь экспорта

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

3. Передайте результаты и очистите место

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

Сначала оцените пиковое использование штатного SSD на 2 ТБ с учётом исходников, кэша и экспортированных файлов. Дополнительный SSD на 2 ТБ заказывайте только при реальной необходимости, а не по умолчанию.