В CI нестабильный автотест периодически блокирует слияние изменений. Какой процесс позволит временно убрать его из гейта, не потеряв контроль над исправлением?
Используйте управляемый quarantine-процесс: временно исключите нестабильный тест из обязательного гейта, но сохраните его в отдельном запуске с явной пометкой, владельцем, задачей на исправление и сроком возврата. Простое отключение теста скрывает дефекты, а карантин отделяет проблему стабильности теста от результата основной проверки.
По мере роста автотестов стало важно различать дефект продукта и дефект самого теста или тестовой инфраструктуры. Нестабильный тест может случайно падать при неизменном коде, поэтому его единичный результат перестаёт быть надёжным критерием для блокировки поставки.
Карантин появился как операционный компромисс: команда сохраняет сигнал о проблемном тесте, но не позволяет известной нестабильности постоянно останавливать разработку. Это не замена исправлению, а временный режим управления риском.
Если нестабильный тест остаётся обязательным, команда привыкает повторно запускать сборку и игнорировать красные результаты. Так снижается доверие к CI, а реальные регрессии могут затеряться среди ложных сбоев.
Если тест просто удалить или отключить навсегда, исчезает автоматическая проверка соответствующего поведения. Кроме того, без владельца и срока возврата временное исключение обычно становится постоянным.
Для теста в карантине следует зафиксировать причину нестабильности, владельца, ссылку на задачу, дату помещения и критерии выхода. Основной гейт не учитывает его результат, но отдельный job продолжает запускать тест и публиковать статистику: долю сбоев, успешных повторов, длительность и характер ошибок.
Важно различать нестабильность и постоянный функциональный дефект. Если тест стабильно падает на корректном сценарии, его нельзя считать flaky и безопасно исключать из гейта: нужно исправить продукт или тестовые ожидания.
Карантин должен иметь ограниченный срок действия или автоматическое оповещение об истечении. Возврат в обязательный набор выполняют после устранения причины и подтверждения стабильности на серии запусков, причём критерий должен учитывать не только один зелёный прогон.
Обычно применяют отдельный набор или метку для карантинных тестов. Их нельзя смешивать с обычными повторами: retry может уменьшить влияние случайного сбоя на один запуск, но не устраняет нестабильность и не создаёт процесса её устранения.
Компромисс состоит в том, что на время карантина команда теряет часть защитного покрытия в гейте. Поэтому карантин допустим только для ограниченного числа тестов, с видимой метрикой накопленного риска и регулярным контролем срока пребывания.
UI-тест оформления заказа иногда падал из-за гонки между обновлением страницы и появлением итогового состояния. Вариант оставить его в гейте с тремя повторами давал зелёные сборки, но скрывал проблему и увеличивал время CI. Полное отключение ускоряло пайплайн, однако убирало проверку критического сценария.
Команда поместила тест в карантин, назначила владельца, сохранила его в отдельном обязательном для наблюдения запуске и добавила срок возврата. Параллельно исправили ожидание состояния, затем проверили тест на серии запусков и вернули его в основной гейт. В результате слияния перестали блокироваться случайными сбоями, а сам дефект стабильности не исчез из зоны ответственности.
Карантин сохраняет тест в системе контроля: он продолжает выполняться, его результат виден, а исправление имеет владельца и срок. При отключении тест обычно перестаёт давать сигнал, поэтому команда может не заметить, что важное покрытие утрачено.
Не обязательно. Нестабильность может проявляться редко или зависеть от нагрузки, порядка выполнения и окружения. Нужно проверить тест на репрезентативной серии запусков, убедиться в устранении первопричины и оценить повторяемость результата, а не только получить несколько зелёных прогонов подряд.
Это сигнал, что процесс используется как постоянный обход проблемы. Следует ограничить число и срок карантинов, анализировать причины по категориям, назначить приоритеты исправления и включить метрику карантинных тестов в контроль качества CI. При достижении лимита новые исключения должны требовать отдельного согласования, иначе гейт постепенно потеряет смысл.