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

Материал пригодится ИТ- и платформенным руководителям, которые отвечают за рабочие процессы Xcode Cloud и командный CI.
Руководители UI-тестирования смогут отделить обязательный регрессионный прогон от частых проверок веток.
Команды выпуска разберутся, как не спутать отменённую сборку с завершённой поставкой.

Разделите проверки на заменяемые и обязательные

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

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

Для принятия решения задайте команде два вопроса:

  • Можно ли без потери смысла повторить эту задачу на более свежем коммите?
  • Нужен ли результат текущего запуска для выпуска, аудита, расследования сбоя или подтверждения конкретного изменения?

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

Отменит ли Xcode Cloud уже выполняющуюся задачу?
Может отменить: официальное описание связывает автоматическую отмену с новым запуском того же рабочего процесса и его текущей сборкой. Проверяйте именно журнал своей конфигурации — не полагайтесь на предположение, что настройка удаляет все ожидающие задачи или действует на любые рабочие процессы. Описание параметров рабочего процесса нужно сопоставить с фактическим статусом конкретного запуска.

Настройте проверку ветки без накопления устаревших запусков

Для проверки ветки полезно отделить событие запуска от политики отмены. Сначала определите, какие изменения должны запускать рабочий процесс: например, обновление выбранной ветки или изменение, поступившее через запрос на слияние. В справочнике Apple перечислены условия запуска, настраиваемые в рабочем процессе; доступные пункты и их описание проверьте в интерфейсе Xcode Cloud, прежде чем менять действующую схему. Руководство по первому рабочему процессу показывает, где задаются базовые условия запуска.

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

Чтобы проверить поведение до изменения общего процесса:

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

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

Выберите режим для каждой ситуации

Сценарий Решение по автоматической отмене Что проверить перед внедрением
Проверка ветки после каждого изменения Обычно включить для рабочего процесса, где новый результат заменяет старую проверку Событие запуска, коммит отменённой сборки, полный результат актуальной проверки
Быстрые последовательные изменения Включить только для заменяемой валидации; независимые диагностические прогоны отделить Есть ли у каждого запуска отдельная ценность для расследования или аудита
UI-регрессия с набором симуляторов Не запускать автоматически на любое изменение без оценки нагрузки и требований к шлюзу Какие изменения требуют UI-прогона и какой статус разрешает слияние
Архивация и распространение Отключить отмену в критическом процессе либо отделить поставку от проверок ветки Существуют ли ожидаемый архив, загрузка, обработка и подтверждение распространения
Фиксированная или частная среда выполнения Разделить задачи между Xcode Cloud и управляемым Mac-узлом по требованиям среды Условия передачи, доступ к зависимостям, подписи, журналы и критерии приёмки

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

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

Сократите лишние UI-прогоны, не ослабляя допуск

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

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

Перед разделением зафиксируйте правило допуска: какие изменения требуют UI-регрессии, где команда видит её результат и какой статус блокирует слияние. Затем проверьте, что отменённый UI-прогон не трактуется автоматизацией как успешный. Apple отдельно описывает просмотр и интерпретацию результатов тестирования; сверяйте фактические результаты тестов, а не только состояние общего запуска. См. документацию о запуске тестов и их результатах.

Важно: отменённый прогон не равен пройденному тесту. Если ваша система допускает слияние только после UI-регрессии, отмена должна оставлять проверку незавершённой или требовать нового успешного запуска — в соответствии с настройками командного шлюза.

Нужно ли запускать UI-тесты при каждом изменении?
Только если каждый такой запуск необходим для решения о допуске изменения. Если полная регрессия нужна в контрольной точке, сделайте её отдельным запуском с явно заданным условием. После изменения схемы проверьте, что нужный UI-результат по-прежнему обязателен для слияния.

Защитите архивирование и распространение

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

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

Приёмку выпуска проводите по конкретным состояниям: проверьте, что сборка создана, архивирование завершилось, загрузка прошла, а нужный этап распространения получил ожидаемый статус. Запуск рабочего процесса не доказывает, что сборка доступна для передачи. Завершение одного действия также не доказывает, что закончены последующие этапы. Для проверки статусов используйте справочник App Store Connect по состояниям сборки и инструкцию по загрузке сборок.

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

Передайте фиксированные задачи на управляемый Mac-узел

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

Не сравнивайте решения по неподтверждённым оценкам скорости или стоимости. Сначала опишите границу передачи: какой триггер создаёт задачу, какие входные данные получает узел, где хранятся журналы, кто управляет подписями и какой результат возвращается в CI. Затем проведите тестовый запуск и сравните журналы, идентификаторы коммитов и критерии успешного завершения. Переменные среды и передаваемые значения сверяйте с официальным справочником по среде Xcode Cloud, не предполагая, что параметры одного контура автоматически доступны другому.

Если рассматриваете удалённый Mac как дополнительный исполнитель, начните с проверки доступа, изоляции учётных данных и способа подключения. Общие сведения о доступных вариантах можно посмотреть на русскоязычной странице MACCOME, а подход к подключению и условиям выполнения сверить с информацией об оформлении удалённого Mac. Это вариант для задач, которым нужна управляемая среда выполнения, а не обязательная замена Xcode Cloud.

Перед выбором сопоставьте плюсы и ограничения:

  • Оставить задачу в Xcode Cloud: проще сохранить единый рабочий процесс, но условия и поведение нужно проверять в рамках его текущей конфигурации.
  • Добавить собственный Mac-узел: можно отдельно управлять средой и передачей результата, но придётся поддерживать доступы, журналы, обновления и приёмку.
  • Разделить выполнение: оставить облачную проверку и передать только подходящие задачи; зато нужно определить явный контракт между этапами и проверять его при каждом изменении схемы.

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

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