Когда прекращается поддержка Rosetta 2? Чек-лист миграции корпоративного Mac CI в 2026 году

Фраза «Rosetta продолжит работать в macOS 27» слишком груба для корпоративного решения. Apple указывает, что macOS 27 — последний основной выпуск с общей поддержкой Rosetta для Intel-only приложений macOS. При этом это не обещание, что любой x86_64-компонент корпоративного пайплайна будет работать без изменений.

Вам нужно разделять четыре разных случая:

• Intel Mac — физический компьютер с Intel-процессором. Его жизненный цикл и совместимость с новыми версиями macOS — отдельный вопрос.
• Intel-only приложение macOS — программа, которая запускается на Apple Silicon через Rosetta.
• Universal Binary — один пакет с отдельными arm64 и x86_64-срезами. Он может работать нативно, но это ещё не доказывает корректность всех подключаемых плагинов.
• Linux VM с Intel-бинарным файлом — другой механизм. Документация Apple отдельно описывает запуск Intel-бинарных файлов в Linux-виртуальных машинах; это нельзя автоматически приравнивать к Rosetta для приложений macOS. См. описание запуска Intel-бинарных файлов в Linux VM.

Также не смешивайте наличие Rosetta и фактическую зависимость. На узле может быть установлен переводчик, но конкретная задача уже выполняться в arm64. И наоборот: приложение сборки может быть arm64, а его генератор кода или плагин — x86_64.

Apple предупреждает о возможных уведомлениях о миграции начиная с macOS 26.4 и более поздних выпусков. Эти уведомления полезны для пользователя, но не заменяют инвентаризацию серверного окружения. CI обычно работает без интерактивного сеанса, поэтому окно или системное сообщение не является доказательством успешного запуска.

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

IT-руководитель парка

Ваша задача — определить границы изменения:

• какие Apple Silicon-узлы входят в производственный CI;
• какие версии macOS и Xcode на них установлены;
• какие узлы имеют резервную роль;
• какие задачи нельзя временно переносить на совместимый пул;
• кто утверждает обновление и кто отвечает за откат.

Не объявляйте весь парк готовым только потому, что машины уже куплены на Apple Silicon. Главный риск теперь находится внутри программного слоя: в старых бинарных файлах, установщиках, плагинах и скриптах.

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

Платформенная команда CI/CD

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

Минимальный набор доказательств по каждой критичной задаче:

• лог выбора узла и архитектуры;
• список установленных инструментов;
• архитектура главного процесса и дочерних процессов;
• хэш итогового артефакта;
• результат тестов;
• результат подписи и публикации;
• запись о восстановлении после перезапуска.

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

Владелец инструментов и сборочных компонентов

Для каждого x86_64-компонента выберите одно из трёх решений:

• заменить готовым arm64-релизом;
• пересобрать как arm64 или Universal Binary;
• временно изолировать в списке исключений.

Для внутренних компонентов полезно сравнить руководство Apple по переносу приложений на Apple Silicon с фактической архитектурой проекта. Для Universal Binary используйте официальное руководство Apple по сборке универсального macOS-бинарного файла.

Изолировать компонент можно только при наличии:

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

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

Проверяйте не только основное приложение. В корпоративном Mac CI скрытая зависимость часто находится на периферии цепочки.

В список активов включите:

• исполняемые файлы и динамические библиотеки;
• CLI-инструменты и генераторы кода;
• каталоги пакетного менеджера;
• скрипты установки, pre-build и post-build;
• CI-агенты и их плагины;
• LaunchAgent и фоновые сервисы;
• загрузчики внутренних плагинов;
• самописные бинарные файлы;
• установщики и их post-install-сценарии;
• контейнерные или виртуализированные Linux-инструменты.

Карточка актива должна содержать архитектуру, вызывающую задачу, владельца, замену, влияние на выпуск и ссылку на доказательство. Не записывайте только «работает на Apple Silicon». Это слишком слабое утверждение для приёмки.

Минимальная проверка на узле может выглядеть так:

file /path/to/tool
lipo -info /path/to/tool
uname -m
ps -axo pid,command

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

Для каждой записи сохраните дату проверки, путь, команду, лог и владельца. Повторите проверку после обновления пакетного менеджера: новый PATH может вернуть старый x86_64-инструмент даже после успешной замены.

Установка arm64-версии — только начало. Закрывайте миграцию на уровне реального проекта.

Порядок проверки:

1. Зафиксируйте текущий производственный запуск: исходный коммит, версии инструментов, переменные окружения, артефакт и лог.
2. Установите arm64-версию в отдельный узел или рабочий каталог. Не заменяйте единственный стабильный инструмент непосредственно на производственном агенте.
3. Проверьте архитектуру бинарного файла, плагинов и дочерних процессов.
4. Запустите чистую сборку без старого кэша.
5. Выполните unit-тесты, интеграционные тесты и тесты, которые используют подпись или Keychain.
6. Создайте архив и проверьте его содержимое, подпись, хэш и публикацию.
7. Повторите запуск после перезапуска узла и без интерактивного входа пользователя.
8. Сохраните различия логов и решение владельца.

Особое внимание уделите скриптам оболочки. Интерпретатор может быть системным arm64, но вызванная им утилита — Intel. Аналогичный риск возникает при использовании старого каталога пакетного менеджера, бинарного загрузчика плагинов или закрытого генератора.

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

До завершения миграции разделите инфраструктуру на два пула.

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

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

Для двойного прогона выберите репрезентативные операции:

• сборка pull request;
• полный набор тестов;
• архивирование;
• подписание;
• публикация;
• повторный запуск после сбоя;
• восстановление после перезагрузки.

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

Проверяйте кэши отдельно. Кэш, созданный x86_64-инструментом, может маскировать отсутствие arm64-компонента. Чистый запуск и повторный запуск после удаления кэша должны входить в приёмочный сценарий.

Безопасность и автоматическое восстановление — отдельные ворота приёмки. Приложение может запускаться вручную, но ломаться в CI после перезагрузки.

Проверьте:

• доступ к Keychain в безголовом режиме;
• сертификаты и профили подписи;
• проверку кода после сборки;
• нотарификацию и публикацию;
• внутренние плагины;
• системные расширения и фоновые службы;
• запуск LaunchAgent;
• восстановление CI-агента после перезапуска;
• работу без открытой пользовательской сессии.

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

Сохраняйте хэш артефакта, логи подписи, результат проверки и запись согласования. Если команда не может объяснить, какой процесс вызвал Rosetta и зачем он ещё нужен, компонент нельзя считать готовым к производственному macOS 27.

Документация Apple о среде трансляции Rosetta полезна для понимания механизма, но не является доказательством совместимости вашего пайплайна. Такое доказательство появляется только после проверки реальной задачи.

Отметьте пункт только при наличии лога или другого воспроизводимого свидетельства.

• [ ] Для каждого производственного узла назначен владелец.
• [ ] Зафиксированы версия macOS, версия Xcode и архитектура узла.
• [ ] Проверены CLI-инструменты, библиотеки и дочерние процессы.
• [ ] Проверены LaunchAgent, CI-агент и плагины.
• [ ] Проверены пути пакетного менеджера и установочные скрипты.
• [ ] Для каждого x86_64-компонента выбрано: замена, пересборка или исключение.
• [ ] Нативный и совместимый пулы разделены метками или очередями.
• [ ] Кэши и рабочие каталоги между пулами изолированы.
• [ ] Реальный проект прошёл сборку и тесты на arm64.
• [ ] Архив, подпись и публикация проверены на arm64.
• [ ] Узел восстановился после перезапуска без ручного входа.
• [ ] Для исключений указаны владелец и дата вывода.
• [ ] Есть процедура возврата задачи на совместимый узел.
• [ ] Решение об обновлении до macOS 27 утверждено ответственным лицом.

Используйте таблицу не для подсчёта разработчиков, а для сопоставления риска и доказательств.

После инвентаризации рассчитывайте ёмкость по задачам, а не по числу разработчиков. Зафиксируйте:

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

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

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

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

macOS 27 и Intel-приложения

Да, macOS 27 является последним подтверждённым основным выпуском с общей поддержкой Rosetta для Intel-only приложений macOS. Это не означает, что каждый компонент CI гарантированно продолжит работу. Проверяйте фактические процессы, плагины и скрипты. Окончательное решение принимайте по документированным результатам вашего пайплайна, а не по наличию установленной Rosetta.

Проверка зависимости CI от Rosetta

Начните с полного списка файлов и процессов, а не с главного приложения. Используйте file, lipo -info, uname -m и журнал процессов, затем сопоставьте результат с конкретной задачей. Отдельно проверьте PATH, пакетный менеджер, LaunchAgent, CI-агент и дочерние процессы. Каждую найденную зависимость занесите в актив с владельцем и доказательством.

Перенос x86_64-инструментов

Предпочтительный путь — официальный arm64-релиз. Для внутреннего кода выбирайте arm64 или Universal Binary. После замены прогоните чистую сборку, тесты, архивирование, подпись и публикацию на реальном проекте. Если зависимость закрытая и замены нет, оформите временное исключение. Сам факт успешной установки нового бинарного файла миграцию не завершает.

Совместимый пул

Совместимый пул следует сохранить на переходный период, если есть активные x86_64-зависимости или не завершена приёмка. Разделите его от нативного пула, запретите новые постоянные зависимости и назначьте дату пересмотра. После того как критичные задачи получили arm64-доказательства, уменьшайте пул. Не оставляйте его без владельца: тогда временная среда станет неуправляемой.

Поломка скриптов после исчезновения Rosetta

В зоне риска находятся не только команды Xcode. Ошибки возможны в генераторах, установщиках, post-build-скриптах, динамических библиотеках, плагинах, LaunchAgent и закрытых утилитах. Особый риск возникает, когда arm64-процесс запускает x86_64-дочерний процесс. Проверяйте чистый запуск, подписанный артефакт, публикацию и восстановление после перезапуска.

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

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

Аренда удалённого Mac удобнее для пилота и временного расширения, но вы всё равно должны проверить права доступа, журналирование, сетевой маршрут, хранение секретов, удаление данных и процедуру аварийного восстановления. Для тестовой группы можно начать с заказа удалённого Mac в CALMVPS, а затем сопоставить результаты с политикой вашей организации.

Если текущая схема — один общий Intel-узел или неподконтрольный старый Mac — её слабые места очевидны: единая точка отказа, скрытые x86_64-зависимости, ручное восстановление и невозможность безопасно провести двойную проверку без остановки релизов. Временный удалённый Apple Silicon-узел позволяет изолировать эксперимент, прогнать реальные задачи и собрать доказательства до расширения закупки. Это не отменяет требования к безопасности, но обычно лучше соответствует короткому окну миграции, чем поспешная покупка оборудования без подтверждённой архитектуры пайплайна.

Ваш следующий шаг — создать отдельный arm64-узел, подключить к нему ограниченный набор реальных CI-задач и оформить результаты по чек-листу. После проверки подписи, артефактов и восстановления вы сможете обоснованно выбрать постоянную закупку, расширение аренды или смешанный пул, а не сохранять Rosetta-зависимость только потому, что она пока ещё запускается.