Как долго хранить артефакты CI на Mac в компании? Стратегия 2026

Apple указывает, что для символизации отчёта о сбое нужны подходящие отладочные символы, а сопоставление выполняется по UUID бинарного файла и dSYM (документация Apple о добавлении имён символов в отчёт о сбое). Практический вывод для корпоративной Mac CI прост: не назначайте всем данным один срок хранения. Сохраняйте архивы выпущенных версий и соответствующие им dSYM с учётом диагностики и аудита; логи, отчёты, кэш и временные каталоги регулируйте отдельно. Долгосрочные материалы выносите из рабочего пространства сборочного узла.

Материал предназначен руководителям iOS-релизов, которым нужны проверяемые правила хранения Xcode archive и dSYM.
Платформенные инженеры найдут подход к кэшу, логам и очистке Mac Runner без риска для релизных данных.
Специалисты IT, безопасности и аудита смогут закрепить места хранения, права, ответственность и проверку восстановления.

Почему общая политика хранения создаёт риск

Артефакты CI — не единый тип данных. Одни нужны для восстановления опубликованного релиза или разбора сбоя, другие можно пересоздать из исходников и зависимостей. Если всё попадает под одну настройку очистки, вы либо удаляете нужное для диагностики, либо удерживаете кэш и рабочие каталоги без ясной причины.

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

Для принятия решения разберите минимум четыре ограничения:

• Восстановление. Наличие исходного кода не гарантирует, что можно получить тот же опубликованный пакет и его отладочные символы. Важны фактически сохранённые материалы релиза.
• Диагностика. dSYM должен соответствовать бинарному файлу. Файл символов от другой сборки не становится подходящим только потому, что исходники похожи.
• Аудит. Сам пакет приложения может не подтвердить, какой запуск CI его создал, какие проверки прошли и кто разрешил публикацию.
• Эксплуатация узла. Mac Runner одновременно содержит ценные материалы и данные, предназначенные для пересоздания. Очистка без разделения каталогов повышает риск случайного удаления; отказ одного узла может лишить команду единственной копии.

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

Классы данных и сравнительная оценка риска

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

Разделите содержимое CI на классы:

• Релизные материалы: Xcode archive, экспортированный пакет приложения, dSYM и записи, связывающие их с версией, сборкой и выпуском. Риск при утрате — высокий: вы можете лишиться возможности корректно разбирать сбои или подтвердить состав выпущенного комплекта.
• Результаты проверок: отчёты тестов, результаты статического анализа и другие данные, на которые ссылаются при разборе дефекта или приёмке релиза. Риск зависит от того, как долго вам нужны доказательства проверки и кто должен иметь к ним доступ.
• Логи сборки и публикации: нужны, чтобы восстановить последовательность событий и локализовать сбой. Их полезность обычно ограничена периодом диагностики и внутренними правилами, поэтому срок задавайте отдельно от релизного архива.
• Зависимости и кэш: ускоряют повторные сборки, но сами по себе не заменяют опубликованный артефакт или доказательство проверки. В документации GitHub отдельно рассматриваются кэш зависимостей и workflow artifacts как данные с разным назначением (описание кэширования зависимостей и отличие кэша от артефактов).
• Временная рабочая область: промежуточные файлы и каталоги, которые можно создать заново в рамках пайплайна. Их очищают по операционным правилам, предварительно проверив, что в каталог не попали данные релиза или единственная копия диагностических материалов.

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

Можно ли после удаления Xcode archive использовать dSYM для символизации сбоя? Сам по себе dSYM может содержать символы, необходимые для сопоставления с бинарным файлом, но его наличие не означает, что у вас сохранены все материалы релиза и контекст сборки. Храните подходящий dSYM вместе с данными, позволяющими установить его связь с выпущенным приложением; при разборе сверяйте UUID по описанному Apple процессу (инструкция Apple по символизации отчёта о сбое). Не считайте archive и dSYM взаимозаменяемыми: их роли различаются.

Связь релиза, архива и символов

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

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

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

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

Не оставляйте единственные копии в домашнем каталоге пользователя, временной рабочей области или каталоге, который очищается вместе с Mac Runner. Это не означает, что всем организациям нужна одна и та же система хранения. Выбирайте место по требованиям к доступу, резервированию, целостности, срокам и управлению данными; обязательно документируйте расположение и восстановление.

Отдельные сроки для логов, отчётов и кэша

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

Должны ли логи, отчёты тестов и кэш Mac CI иметь одинаковый срок хранения? Нет: задавайте срок каждому классу по его назначению, потребности в диагностике, требованиям аудита и стоимости восстановления. Один общий срок упрощает настройку, но смешивает данные, потеря которых означает исчезновение доказательств, с данными, которые можно пересоздать.

Время удержания не следует угадывать или выдавать за отраслевой стандарт. Определите его вместе с владельцами релиза, CI-платформы и контроля данных:

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

Настройки конкретной CI-платформы — механизм исполнения, а не готовая корпоративная политика. Документация GitHub описывает управление сроками хранения логов и артефактов на уровне организации, а также отдельные настройки для artifact в workflow (параметры хранения логов и артефактов на уровне организации, сохранение данных workflow и настройки отдельного artifact). Перед внедрением проверяйте область действия каждой настройки и её приоритет: правила организации, проекта или конкретного артефакта могут различаться.

Такая же осторожность нужна при работе с другими платформами. GitLab описывает настройки срока действия job artifacts и особое поведение, связанное с артефактами последнего успешного pipeline (документация GitLab по job artifacts); в Azure DevOps правила retention для запусков и тестовых данных представлены в документации самой платформы (политики хранения данных в Azure Pipelines). Не переносите поведение одного сервиса на другой и проверяйте актуальные параметры именно в применяемом вами продукте.

Кэш очищайте только после проверки восстановления. В документации GitHub описаны отдельные условия использования и удаления кэша зависимостей (справка GitHub по кэшированию зависимостей и правилам очистки). Это полезный пример того, почему слово «кэш» не означает, что каталог можно без проверки исключить из инвентаризации: сначала установите его владельца, содержимое и последствия повторного получения зависимостей.

Практический маршрут для внедрения политики

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

• [ ] Инвентаризируйте источники. Найдите, где CI сохраняет archive, dSYM, экспортированные приложения, отчёты, логи, кэш и рабочие каталоги. Уточните, какие материалы остаются на Mac Runner, а какие уже перенаправляются в независимое хранилище.
• [ ] Определите владельца каждого класса. Назначьте владельца релизных файлов, логов, результатов тестов и кэша. Если за данные не отвечает конкретная роль, никто не подтвердит, можно ли их удалять и кому понадобится восстановление.
• [ ] Свяжите релизные файлы с запуском. Сохраняйте версию, идентификатор сборки, расположение архива и dSYM, экспортированный пакет и ссылку на запуск. Проверьте соответствие бинарного файла и символов по UUID, а не только по имени.
• [ ] Задайте раздельные правила. Зафиксируйте основания и условия истечения для каждой категории. Для релизных материалов учтите диагностику и аудит; для логов и отчётов — потребность расследования и подтверждения; для кэша — возможность восстановления; для временных данных — момент, когда их очистка безопасна.
• [ ] Проверьте права и удаление. Определите, кто может читать релизные файлы, переносить их, менять настройки retention и удалять данные. Убедитесь, что автоматический процесс очистки не имеет доступа к каталогам с единственными копиями релизных материалов.
• [ ] Восстановите выборочный релиз. Возьмите выпущенную версию и проверьте, что команда находит соответствующие archive и dSYM, может связать их с приложением и получить необходимые данные без доступа к исходному Mac Runner.
• [ ] Сверьте очистку с настройками платформы. Проверьте уровни настроек CI и их фактическое поведение после истечения срока. Зафиксируйте результат проверки, а не только предполагаемые значения конфигурации.
• [ ] Назначьте повторный пересмотр. Пересматривайте правила при смене CI-платформы, схемы публикации, требований безопасности или ответственных команд. Запись о пересмотре должна содержать владельца и подтверждение, что восстановление по-прежнему работает.

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

Проверка устойчивости и ответственности

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

• Можно ли найти archive и соответствующий dSYM для выбранного выпущенного приложения?
• Сопоставлены ли символы с бинарным файлом, а не только с похожим названием сборки?
• Известно ли, кто имеет право читать релизные материалы и кто может удалить их?
• Сохраняются ли отчёты и логи согласно утверждённому назначению, а не случайной настройке узла?
• Подтверждено ли, что кэш и временную область можно восстановить или пересоздать?
• Проверено ли получение нужных файлов из хранилища, независимого от Mac Runner?
• Зафиксированы ли результат проверки, ответственный и местоположение доказательств?

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

Выбор подхода к ресурсам Mac CI

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

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

Особенно уязвима схема, в которой текущий сборочный узел одновременно служит единственным хранилищем релизов. Она связывает сохранность данных с состоянием одного компьютера, делает очистку рабочего диска опасной и затрудняет независимую проверку доступа. Для временного расширения команды или тестирования новой схемы сборки удалённый Mac может быть удобным дополнительным ресурсом, если постоянные артефакты вы храните отдельно. В материалах VPSMAC о доступных узлах Mac можно проверить варианты для планирования такого CI-ресурса; это не заменяет проверку вашей схемы хранения. Если узел нужен для постоянной тяжёлой нагрузки или физической периферии, сначала оцените покупку и эксплуатацию собственного оборудования. Для переменной потребности сверьте, подходит ли вам аренда Mac для CI, и до подключения закрепите правила передачи данных, доступа и восстановления.

Итоговое решение должно быть проверяемым: у каждой категории есть цель, владелец и основание для срока, а релизные archive и dSYM доступны независимо от очищаемого рабочего пространства. Начните с выборочной проверки опубликованной версии на текущем Mac Runner; если восстановление зависит от локального каталога или одного узла, сначала устраните эту зависимость, а уже затем настраивайте автоматическую очистку.