Регресс в 40 минут на каждый merge request: как ужать до 20 без потери сигнала
На каждый merge request в пайплайне выполняется полный регресс: 480 тестов, около 40 минут. Разработчики жалуются, что ждут проверку дольше, чем пишут код, и начали сливать изменения в обход правил.
Нужно уложиться примерно в 20 минут, не теряя контроль качества.
Что делать?
- Удалить самые долгие тесты: они всё равно падают чаще остальных и держат весь пайплайн
- Оставить только UI-тесты: они проходят пользовательский путь целиком и заменяют проверки на уровне API
- Разделить прогон: быстрый набор критичных сценариев на каждый merge request, полный регресс ночью, плюс распараллелить тесты по потокам
- Запускать регресс вручную и только перед релизом, а merge request проверять на код-ревью