Объясните, как выстроить CI-пайплайн, чтобы быстрый smoke-сигнал не ждал полного регресса, но слияние блокировалось его результатом?
Нужно разделить пайплайн на независимые стадии: быстрый smoke-набор запускать сразу, а полный регресс — параллельно или после него в отдельной ветке графа. Система должна отдельно публиковать ранний результат для разработчиков, но финальное правило слияния должно учитывать обязательный результат полного регресса.
Важно не путать быстрый сигнал с окончательным разрешением на слияние. Smoke помогает быстро обнаружить критическую поломку, а полный регресс обеспечивает более широкую проверку перед приемкой изменения.
По мере роста автотестов единый последовательный прогон перестал обеспечивать приемлемую скорость обратной связи. Если сначала запускать все быстрые тесты, а затем полный набор, даже небольшое изменение может долго ждать результата менее приоритетных проверок.
Разделение пайплайна на стадии и параллельные ветви возникло как способ совместить две цели: быстро сообщить о наиболее опасных сбоях и сохранить обязательную глубокую проверку качества. Это не отменяет тесты, а меняет порядок и форму получения результатов.
Предположим, smoke-набор выполняется за несколько минут, а полный регресс — значительно дольше. При последовательном запуске разработчик получает даже очевидную ошибку с задержкой, потому что быстрый результат может быть скрыт за очередью или зависеть от завершения полного набора.
Обратная крайность тоже опасна: если разрешать слияние сразу после успешного smoke, изменения могут попасть в основную ветку до завершения регресса. Дополнительные риски создают отмена длительных проверок, потеря их результатов и неоднозначное правило, какой статус считать окончательным.
Пайплайн следует представить как граф зависимостей. После сборки и подготовки окружения запускаются как минимум две ветви: обязательный smoke и полный регресс. Smoke публикует ранний статус, а регресс продолжает выполняться независимо, если нет причины немедленно прекратить весь запуск.
Для слияния задаётся отдельное правило: обязательными являются успешная сборка, smoke и полный регресс. Если smoke завершился ошибкой, можно сразу сообщить о проблеме и при необходимости отменить менее полезные длительные проверки. Но такая оптимизация допустима только тогда, когда команда принимает потерю диагностического результата регресса.
Статусы должны быть различимыми. Например, состояние smoke не должно подменять состояние полного регресса, а незавершённая проверка не должна трактоваться как успешная. Для каждого запуска полезно сохранять отчёты, логи и идентификаторы сборки, чтобы результат можно было связать с конкретным состоянием исходного кода.
Если полный регресс запускается параллельно, нужно учитывать конкуренцию за окружение, базу данных и внешние ресурсы. В противном случае ускорение графа может привести к взаимному влиянию тестов и снизить достоверность результатов.
Главный компромисс — между скоростью раннего сигнала и стоимостью вычислений. Параллельный запуск сокращает календарное время, но требует больше ресурсов; последовательный запуск экономнее, однако ухудшает обратную связь. Если полный регресс запускается после smoke, инфраструктура проще, но задержка до его результата больше.
Команда запускала smoke, интеграционные проверки и UI-регресс последовательно. Smoke занимал четыре минуты, а весь регресс — около сорока; при этом слияние разрешалось только после завершения последней стадии. Разработчики часто начинали разбирать проблему спустя десятки минут, хотя ошибка уже была видна в smoke.
Рассматривались три варианта. Полностью разрешить слияние после smoke было быстро, но создавало риск пропуска дефектов; запускать только полный регресс было надёжнее, но сохраняло медленную обратную связь; параллелить все проверки давало лучший результат по времени, но требовало выделенных окружений и контроля конфликтов за тестовые ресурсы.
Выбрали третий вариант: smoke и регресс запускались параллельно, smoke отображался как ранний сигнал, а правило слияния ожидало оба обязательных статуса. При критическом сбое smoke разработчик получал уведомление сразу, а длительный регресс отменяли только для изменений, для которых его дальнейший запуск не давал полезной информации. В результате время обнаружения очевидных проблем сократилось, а окончательное правило качества осталось строгим.
Нет. Параллельность только меняет время выполнения, но не определяет, какие результаты обязательны. Без явного правила слияния система может принять изменение после smoke, пока полный регресс ещё выполняется или уже завершился ошибкой.
Нужно определить обязательные проверки, состояния ожидания и поведение при инфраструктурном сбое. Обычно незавершённый или неуспешный обязательный job не должен считаться успешным сигналом.
Нет, это зависит от ценности оставшейся диагностики. Если smoke выявляет ошибку сборки, из-за которой остальные тесты заведомо неинформативны, отмена экономит ресурсы. Но если smoke проверяет только часть системы, полный регресс может обнаружить независимые проблемы и предоставить команде полезные сведения.
Решение должно учитывать стоимость запуска, доступность ресурсов и необходимость получить полный отчёт. Автоматическая отмена без анализа зависимостей может ухудшить диагностику и скрыть вторичные дефекты.
У них разные назначения и жизненные циклы. Smoke отвечает на вопрос, не сломаны ли основные критические функции настолько, чтобы немедленно обратить внимание команды; полный регресс проверяет более широкий набор поведения и может завершиться позже.
В интерфейсе CI и правилах защиты ветки эти результаты следует представлять отдельными статусами. Раннее уведомление может быть информативным, но только явно объявленные обязательные проверки должны влиять на разрешение слияния.