Нумерация сборок iOS в облачном Mac CI
Центральный счётчик, явная передача параметров Xcode и проверка архива предотвращают совпадение номеров iOS-сборок в параллельных заданиях.
Читать руководствоОт выбора выделенного физического узла и воспроизведения среды Xcode до SSH-сессий, проверки артефактов сборки и планирования изменений системы — каждый материал посвящён командам, контрольным пунктам и сценариям сбоя.
Сейчас показано 3 руководства
Краткое описание карточки сразу показывает сценарий применения, ключевые действия и результат проверки. Фильтр меняет только представление материалов на текущей странице, не открывая другую страницу и не сбрасывая позицию чтения.
Центральный счётчик, явная передача параметров Xcode и проверка архива предотвращают совпадение номеров iOS-сборок в параллельных заданиях.
Читать руководствоПодключаем Thread Sanitizer к iOS CI на облачном Mac: отдельный план тестов, повторные запуски, сохранение xcresult и разбор стеков конфликтующих обращений.
Читать руководствоПодключите DocC к CI на облачном Mac, зафиксируйте среду Xcode, блокируйте неверные ссылки на символы и сохраняйте воспроизводимый статический сайт документации.
Читать руководствоПроблемы облачной сборки обычно возникают не только в компиляторе. Если отличаются путь к Xcode, кэш зависимостей, доступ к материалам подписи, цели тестирования или экспорт артефактов, задача, успешная локально, может завершиться ошибкой в автоматизированной среде.
Настроить среду пошаговоСначала запишите версию системы, полную версию Xcode и текущий каталог проекта, а затем проверьте, куда указывает xcode-select . В CI-задаче явно указывайте рабочий каталог, scheme, configuration и путь вывода, чтобы не наследовать временные параметры интерактивной сессии.
Кэш загруженных зависимостей можно переиспользовать по хэшу lock-файла, а DerivedData и промежуточные артефакты следует изолировать по ветке, версии Xcode и целевой платформе. Даже после попадания в кэш выполните чистую сборку, чтобы исключить скрытые зависимости.
Сначала проверьте профили подготовки, доступность сертификатов, идентификатор Bundle и настройки экспорта, затем запускайте archive и export. Fastlane должен сохранять шаг сбоя, код завершения и обезличенный журнал; после передачи артефакта проверьте его размер и хэш.
Задачи командной строки выполняйте преимущественно через SSH. Если нужен графический интерфейс Xcode, настройте разрешение, частоту кадров и качество цветопередачи с учётом качества сети. Для кода, кэша сборки и крупных ресурсов выбирайте разные каналы передачи.
Читать руководство по удалённому подключениюПроверьте адрес узла, имя пользователя, права доступа к ключу и отпечаток хоста. После подключения сначала проверьте версию системы, свободное место на диске и права текущего пользователя.
Git подходит для отслеживаемого исходного кода, SFTP — для небольшого числа конфигурационных файлов, а архив — для разовой передачи больших каталогов. После передачи проверьте целостность по хэшу.
Выйдите из графической сессии, закройте ненужные перенаправленные порты и удалите временную локальную конфигурацию. При обнаружении раскрытия учётных данных немедленно замените их и зафиксируйте область воздействия.
Выделенный физический узел работает 365 дней в году. Если нужно изменить версию системы, команда должна запланировать изменение с учётом зависимостей инструментов и заранее выполнить проверку совместимости, резервное копирование и подготовку к откату.
Зафиксируйте версии macOS, Xcode, Swift, менеджеров зависимостей, сред выполнения и ключевых компонентов командной строки. Для проектов, которые нельзя обновить, укажите причину и альтернативу.
Проверьте минимальную целевую версию развёртывания, сторонние зависимости, скрипты сборки и плагины CI. Сначала запустите тестовую сборку, затем проверьте archive, экспорт и артефакт.
Исходный код должен храниться в репозитории. Конфигурацию и материалы ключей сохраняйте отдельно и безопасно. Резервируйте только данные, необходимые для восстановления работы, не считая временный кэш активом для переноса.
Заранее укажите, какие сбои тестов требуют остановить изменение, и запишите исходную версию, порядок восстановления и команды проверки. После отката повторно проверьте права, пути и автоматизированные задачи.
Выделенный физический узел OpsVM — не виртуальная машина. Он подходит для рабочих процессов, которым нужны постоянная доступность, фиксированная среда и доступ из разных регионов; локальное устройство лучше для задач, тесно связанных с периферией, частой работой офлайн или отсутствием потребности в общей среде.
| Критерий | Выделенный физический узел с Mac в облаке | Локальное устройство разработки | Рекомендация |
|---|---|---|---|
| Пределы производительности | Фиксированная конфигурация не занимает личное устройство и позволяет непрерывно выполнять сборки и тесты. | Низкая задержка взаимодействия, но сборки конкурируют за ресурсы с повседневной разработкой, встречами и локальными приложениями. | Для длинных пайплайнов выбирайте облако, а для отладки с активным взаимодействием оставляйте локальную среду. |
| Доступность | Удалённое подключение через выбранный узел подходит распределённым командам и асинхронным задачам. | Зависит от сети, питания и условий, в которых находится и используется устройство. | При необходимости постоянного доступа выбирайте облако и заранее измерьте задержку в офисной сети. |
| Операционная нагрузка | Команда может централизованно фиксировать версии, зависимости, права и шаги восстановления. | Каждый участник обслуживает среду отдельно, поэтому различия постепенно накапливаются. | Если многие используют одну базовую конфигурацию сборки, централизованную среду проще воспроизводить. |
| Командная работа | Точки входа задач, журналы, кэш и пути к артефактам можно стандартизировать. | Персонализация гибкая, но при передаче проекта приходится заново объяснять различия сред. | Используйте облачный узел для общей цепочки сборки, а локальные устройства оставьте для индивидуального редактирования. |
Анализ размера приложения, сжатие ресурсов и кодирование не должны выполняться лишь однажды на компьютере разработчика. Включите входные данные, параметры, пороги, журналы и выходные файлы в автоматизированный процесс — так команда сможет сравнивать реальный эффект каждого изменения.
Разделите данные на изображения, аудио, видео, шрифты, архитектурные срезы и файлы символов; зафиксируйте исходный размер, способ сжатия и наличие повторных ссылок.
Запишите качество сжатия, формат кодирования, целевое разрешение и правила исключения в скрипт, не полагаясь на память или временные настройки графических инструментов.
Проверьте результаты archive и экспорта по списку файлов, архитектурам, символам и размеру приложения, а не только по объёму ресурсов в каталоге исходного кода.
Задайте пороги для общего размера, размера отдельных файлов и изменений между сборками, архивируйте отчёт вместе с артефактами и возвращайте понятный код завершения при превышении порога.
Каждая карточка содержит категорию, заголовок, описание на 60–100 слов, дату публикации и ссылку для чтения. В описании указываются задача, ключевые шаги и ожидаемый результат проверки; непроверенные просмотры, популярность и оценки не показываются.
Выберите одну из трёх конфигураций Apple Silicon под текущую нагрузку сборки или начните с руководства для первых шагов, чтобы проверить узел, период, диск и инструменты подключения.