Пайплайн стал на 20% медленнее после расширения набора тестов. Чем проверить, ухудшилась ли скорость обратной связи на самом деле?
Сравнивать нужно не только общее время пайплайна, а сопоставимые компоненты его работы относительно прежнего базового уровня. Следует разделить время ожидания и выполнения, учитывать объём и степень параллелизма тестов, а для оценки стабильности смотреть медиану и высокие перцентили, например p95.
Сам по себе рост длительности на 20% не доказывает ухудшение процесса: набор проверок мог вырасти сильнее, а фактическое время получения результата для разработчика — не измениться.
Ранние оценки производительности тестирования часто сводились к среднему времени полного прогона. Такой показатель был понятен, но плохо объяснял причины задержек: тесты могли дольше выполняться, задания могли ждать свободный агент, а пайплайн мог включать больше обязательных стадий.
С развитием непрерывной интеграции важным стал не размер тестового набора сам по себе, а скорость и предсказуемость обратной связи по изменению. Поэтому оценку стали строить на разложении времени процесса и сравнении с контролируемым базовым уровнем.
После добавления тестов общий pipeline time увеличился. Если объявить это ухудшением качества процесса без дополнительного анализа, команда может удалить полезные проверки, хотя задержка возникла из-за увеличения объёма покрытия.
Обратная связь может замедлиться по разным причинам: выросло фактическое время выполнения, увеличилась очередь на CI-агенты, ухудшилась параллельность, появился нестабильный тест с повторными запусками или обязательным стал новый медленный этап. У каждой причины своё исправление.
Сначала фиксируют baseline: длительность сопоставимых пайплайнов до изменения, желательно для одинаковых типов событий и при тех же ресурсах. После этого измеряют как минимум:
Для сравнения используют нормализованные показатели, например длительность тестовой стадии на фиксированный набор проверок или производительность контрольного набора. Однако деление времени на число тестов нельзя считать универсальной метрикой: тесты имеют разную стоимость, выполняются параллельно и могут конкурировать за общие ресурсы.
Важно различать время выполнения и время до обратной связи. Если тесты стали выполняться дольше, оптимизируют сами проверки, фикстуры, данные и инфраструктуру. Если выросло ожидание, увеличивают доступные ресурсы или меняют планирование. Если тормозит критический путь, ищут возможность распараллелить независимые проверки, не ослабляя обязательный quality gate.
Среднее значение полезно для общей оценки затрат, но может скрыть редкие очень долгие прогоны. Медиана показывает типичный результат, а p95 — риск того, что разработчик столкнётся с существенно более медленной обратной связью. Метрики следует интерпретировать вместе с качеством тестов: сокращение времени за счёт удаления проверок не является улучшением.
После добавления интеграционных тестов среднее время пайплайна выросло. Команда рассматривала три варианта: удалить новые проверки, увеличить число CI-агентов или переразбить тесты.
Удаление тестов дало бы быструю обратную связь, но снизило бы защищённость. Простое увеличение агентов могло уменьшить очередь, однако не помогло бы, если узким местом был последовательный критический этап. Безусловное распараллеливание тоже рискованно: общие тестовые данные и ограниченные внешние ресурсы могут вызвать взаимные помехи.
Команда выбрала разложение времени на очередь, выполнение и критический путь, затем выделила независимые группы и сохранила обязательные проверки. В результате стало понятно, какая часть задержки связана с ресурсами, а какая — с реальной стоимостью тестов; оптимизация была направлена на узкое место, а не на весь набор целиком.
Такое отношение не учитывает различия в стоимости тестов, параллельное выполнение, подготовку окружения и общие этапы. Два набора с одинаковым числом тестов могут иметь разную длительность, а добавление дешёвых тестов иногда почти не меняет критический путь. Нормализация по числу тестов годится только как вспомогательный показатель при стабильной структуре набора.
Типичный пайплайн остаётся быстрым, но редкие прогоны стали значительно дольше. Это может указывать на нехватку агентов, конкуренцию за ресурсы, зависимость от внешней системы или нестабильные тесты. Для пользовательского опыта разработчиков такой рост важен: именно длинный хвост распределения создаёт непредсказуемые задержки.
Да, если оно достигнуто отключением обязательных проверок, чрезмерным увеличением числа разрешённых сбоев или исключением сложных сценариев. Метрику скорости нужно рассматривать вместе с дефектами после релиза, долей пропущенных проверок и изменением состава quality gate. Улучшение процесса — это уменьшение задержки при сохранении требуемого уровня обнаружения рисков.