Выбор тестов для сгенерированных изменений, который экономит время CI

Почему даже мелкие правки запускают все тесты

Многие сгенерированные правки очень малы. Один промпт меняет правило валидации, переименовывает поле или меняет хелпер в одной папке. Дифф небольшой, но пайплайн CI часто реагирует так, будто поменялся весь продукт.

Большинство команд начинают с самого безопасного правила, которое можно отстоять: запускать всё при каждом изменении. Это просто объяснить, просто автоматизировать и с ним трудно спорить, когда никто полностью не уверен в связи между файлами и тестами. Если что‑то проскользнёт, первым обвинят логику селекции.

На это есть практическая причина. Многие репозитории выросли без явной карты зависимостей между путями файлов и областями тестов. Изменение в одном месте может повлиять на общие типы, шаги сборки, сгенерированные клиенты или настройки деплоя где‑то ещё. Когда никто не может сказать, от чего что зависит, полные прогоны кажутся безопаснее.

Этот дефолт закрепляется по простым причинам. Команды редко поддерживают карту зависимостей по мере изменения репозитория. В общие папки постепенно тянутся всё новые импорты. Сгенерированный код попадает в места, которые кажутся локальными, но влияют на несколько модулей. А правила CI остаются простыми, потому что никто не хочет разбираться с пропущенным тестом потом.

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

Медленные проверки меняют и поведение команды. Люди перестают отправлять маленькие правки. Некоторые собирают несвязанные изменения в один PR, чтобы ожидание казалось более оправданным. Другие пропускают локальные проверки и надеются, что CI обнаружит проблемы позже. Ничто из этого не улучшает качество.

Именно поэтому имеет значение выбор тестов для сгенерированных изменений. Цель не в том, чтобы тестировать меньше. Цель — подбирать для каждого изменения самые дешёвые проверки, которые при этом имеют смысл, чтобы мелкая правка не запускала часы чужой работы.

Решите, что считать мелким изменением

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

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

Некоторые пути обычно достаточно безопасны для лёгкого набора проверок. Документы, текст продукта и правки стилей редко требуют полного набора. Это обычно включает README, changelogs, справочный контент, файлы переводов, тексты продукта, таблицы стилей, иконки и примеры/комментарии, которые не влияют на выполнение.

Такие правки всё равно нуждаются в базовой защите. Запускайте линтинг, форматирование, проверку орфографии или быстрый UI‑билд, если путь это предполагает. Это ловит очевидные ошибки без лишних двадцати минут на тесты базы данных и API.

Другие пути сразу должны попадать в более строгий бакет. Аутентификация, биллинг, права доступа, общие API‑контракты и код базы данных редко бывают мелкими, даже если дифф выглядит маленьким. Одна строка в миграции, проверке токена или правиле ценообразования может нарушить реальный пользовательский сценарий.

То же верно для общего кода, который импортируют многие сервисы. Если сгенерированная правка затрагивает основной пакет, рассматривайте её как рискованную, пока не доказано обратное. Команды теряют доверие к селективным прогонкам, когда предполагаемо мелкая правка ломает оформление заказа или вход в систему.

Установите дефолтное правило для всего, что не попадает в известный путь. Неизвестные файлы — не безопасные файлы. Отправляйте их в средний уровень: линт, модульные тесты и сборка для затронутого пакета.

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

Сопоставьте файлы и папки с нужными проверками

Большинство репозиториев уже содержат первый черновик карты тестов. Если ваш код живёт в папках вроде web/, api/, mobile/ или infra/, используйте эту структуру. Хорошие селективные прогоны начинаются с имён, которые команда уже понимает, а не с движка правил, которого никто не хочет читать.

Держите первую версию скучной. Верхнеуровневая папка часто говорит достаточно о том, какие проверки важны. Позже вы можете добавить более тонкие правила для общих библиотек, сгенерированного кода или незручных кросс‑проектных зависимостей.

Простая карта может выглядеть так:

• web/ запускает фронтенд‑модульные тесты, проверки типов и быстрый билд
• api/ запускает бэкенд‑модульные тесты и проверки контрактов
• mobile/ запускает мобильный линт и самый быстрый smoke в симуляторе
• infra/ запускает форматирование, валидацию и проверки политик
• docs/ запускает орфографию и проверки markdown только

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

Нужен также короткий список проверок, которые всегда запускаются вне зависимости от изменённых файлов. Держите его маленьким, иначе идея развалится. Для большинства команд достаточно одной проверки сборки на базовую корректность, одного сканера безопасности/секретов и одного smoke‑теста.

Храните карту в репозитории, рядом с кодом. Небольшой YAML или JSON в папке ci/ хорошо работает: любой может просмотреть изменения вместе с PR, где меняется структура кода. Это важно, когда кто‑то добавляет новую папку и забывает её замапить.

Сделайте файл читабельным. Люди должны понять его за минуту. Если один путь мапится на десять джобов и несколько исключений, логика уже слишком сложна.

Простой пример показывает выгоду. Если сгенерированная правка касается только docs/faq.md, запустите markdown‑проверки и остановитесь. Если она касается api/routes/ и web/src/hooks/, запустите бэкенд и фронтенд‑проверки вместе, плюс короткий список всегда‑запускаемых. Это даст полезное покрытие без оплаты полного набора при каждой правке.

Постройте первую версию маленькими шагами

Начните с того, что команда меняет чаще всего. Посмотрите на неделю‑две pull request'ов и выпишите пути, которые повторяются: docs, UI‑файлы, обработчики API, миграции базы данных, скрипты сборки и общие библиотеки.

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

Для каждого распространённого шаблона пути напишите одно простое правило. Держите его узким. Если кто‑то правит docs/, запускайте орфографию и проверки markdown. Если меняют React‑компонент, запускайте UI‑линт, модульные тесты для этого приложения и, возможно, быстрый билд. Если трогают файл миграции, запускайте проверки схемы и тесты базы данных.

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

Простое развёртывание обычно выглядит так:

• Выберите 5–10 шаблонов путей, которые появляются каждую неделю
• Сопоставьте каждый шаблон с самыми дешёвыми релевантными проверками
• Отправляйте неясные или смешанные изменения в полный набор
• Ведите журнал того, что правило выбрало и что потом упало

Откат важен. Когда правила пересекаются или изменение затрагивает общий код, запускайте всё. То же для сгенерированного кода, который попадает в несколько папок, когда истинный источник не очевиден. Консервативный откат кажется менее хитрым, но он сохраняет доверие.

Через неделю просмотрите результаты с командой. Ищите два типа проблем: правила, которые пропустили поломки, и правила, которые всё ещё запускают слишком много работы. Подправьте и то, и другое.

Одна команда может заметить, что правки в src/ui/ часто подтягивают общие хелперы из src/common/. Это знак расширить правило немного. Другая команда увидит, что правки в markdown почти никогда не требуют тестов приложения — это правило можно оставить быстрым.

Держите первую версию достаточно простой, чтобы люди могли её понять, оспорить и улучшить.

Запускайте самые дешёвые проверки первыми

Порядок важнее, чем многие команды признают. Если первая задача в CI занимает десять минут, люди перестают доверять селективным прогонам и нажимают "run all", чтобы успокоиться.

Начните с проверок, которые быстрые, локальные и легко объяснимые. Форматирование, линт и проверки типов ловят удивительное количество ошибок за минуту, особенно для сгенерированных правок, которые затрагивают много файлов, но почти не меняют поведение.

Простой порядок работает хорошо:

• Сначала запустите проверки форматирования
• Далее линт и проверки типов
• Потом небольшие модульные тесты для затронутой области
• Интеграционные тесты запускайте только когда изменённый код лежит в общем модуле или пересекает сервисы
• Полный набор оставьте для рискованных путей, релизных веток или слабых совпадений в карте

Такой порядок экономит время, потому что каждый шаг отвечает на разный вопрос. Формат и линт говорят, чист ли код для чтения и слияния. Проверки типов показывают, не сломались ли контракты. Небольшие модульные тесты проверяют, работает ли изменённая логика.

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

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

Держите правило отката на случай неопределённости. Если файл ещё не замаплен, или генератор изменил общий шаблон, запускайте более широкий набор. Это медленнее, но сохраняет доверие, пока карта улучшается.

На оптимизированном CI это может сильно сократить потери. PR, который падает из‑за форматирования за 20 секунд, должен останавливаться на этом. Нет смысла ждать интеграционных тестов, которые упадут десять минут спустя по той же причине.

Простой пример из одного pull request

Код‑ассистент открывает PR с четырьмя изменёнными файлами. Правки небольшие, но касаются разных частей проекта, поэтому один общий прогон потратит время зря.

src/ui/ProfileCard.tsx
src/ui/ProfileCard.test.tsx
db/migrations/20260410_add_customer_status.sql
.github/workflows/ci.yml
README.md

UI‑изменение — просто текст в карточке профиля. Это должно запускать линт, быстрые проверки типов (если команда их использует) и тест компонента ProfileCard. Нет нужды в тестах оформления заказа, мобильных тестах или полном прогоне браузера, потому что изменена лишь метка на одном экране.

Миграция требует другого подхода. Запустите проверки схемы, примените миграцию к временной базе и запустите API‑тесты, зависящие от этой таблицы. Если миграция меняет колонку, используемую эндпоинтами работы с клиентами, эти тесты должны запуститься, даже если фронтенд едва изменился.

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

Редактирование README — самый простой случай. Достаточно markdown‑проверки и орфографии. Если README.md — единственный изменённый файл, PR должен завершиться за минуту‑две.

Когда в PR присутствуют все четыре типа файлов, система должна комбинировать релевантные проверки, а не откатываться к полному набору. Разумный результат выглядит так:

• UI‑линт и тест затронутого компонента
• Валидация схемы и dry‑run миграции
• API‑тесты, связанные с изменённой областью базы данных
• Валидация CI‑пайплайна
• Проверки markdown и орфографии

Это всё ещё пропускает медленные браузерные сценарии, нагрузочные тесты и несвязанные сервисные тесты. Для многих команд это превращает 30‑минутный пайплайн в 8–10 минут. В этом и смысл селективных прогонов: сопоставлять каждый файл с минимальным набором проверок, который всё ещё ловит реальные проблемы.

Частые ошибки, подрывающие доверие

Доверие пропадает в тот момент, когда селективные прогоны пропускают баг, который поймал бы полный набор. Один промах заставит разработчиков перестать верить карте, и тогда они начнут требовать запуска всего. Поэтому выбор тестов для сгенерированных изменений должен иметь склонность к безопасности, а не к оптимизму.

Первая ошибка — мапить слишком узко. Правило вроде «изменения в этой папке запускают только этот маленький набор тестов» красиво выглядит, пока папка не начнёт импортировать общий код откуда‑то ещё. Общие библиотеки, конфиги, скрипты сборки, схемы БД и контракты API часто влияют на несколько областей. Если путь может затронуть общее поведение, мапьте его на более широкие проверки.

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

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

Несколько привычек сохраняют систему честной:

• Держите явный откат для неизвестных или рискованных изменений
• Перепроверяйте общие папки чаще, чем изолированные
• Удаляйте дублирующие триггеры, когда два правила вызывают один и тот же медленный тест
• Относитесь к сгенерированным правкам и ручным одинаково

Последний пункт важен. AI может делать аккуратные маленькие изменения, но он также может тронуть код так, что это выглядит локально и при этом ломает общее поведение. Не давайте сгенерированным правкам поблажек. Им нужны те же ограждения и тот же откат.

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

Что измерять после развёртывания

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

Начните с процента промахов. Если селективный прогон сказал, что изменение безопасно, а полный набор, staging или прод позже нашли баг, который пропустили пропущенные тесты, засчитайте это. Даже низкий процент промахов важен. Один промах в платёжной логике может съесть весь выигрыш от пятидесяти чистых PR.

Простое правило: логируйте каждую ускользнувшую ошибку 30–60 дней, затем проверьте, пропускала ли карта путь, который должен был запустить тест. Если да — исправьте правило и отметьте паттерн. Вы хотите уменьшать количество промахов со временем, а не получить идеальные числа в первый день.

Наблюдайте экономию времени

Ещё два показателя покажут, окупается ли система в ежедневной работе:

• общее число CI‑минут до и после развёртывания
• среднее время от открытия PR до получения первого полезного результата
• среднее время ревью мелких изменений
• доля PR, которые используют селективные прогоны

CI‑минуты легко считать, но время ревью зачастую рассказывает лучшую историю. Если разработчики получают фидбек за 6 минут вместо 25, они продолжают работать. Ревью‑еры тратят меньше времени в ожидании зелёных чеков перед мержем простой правки.

Спрашивайте команду, где правила кажутся шумными. Разработчики быстро замечают слишком широкие правила. Если изменение в docs всё ещё запускает половину бэкенд‑проверок, люди перестанут верить карте. Короткая обратная связь помогает: заметка в шаблоне PR или простой еженедельный обзор — часто достаточно.

Держите карту в синхронизации с кодовой базой. Команды перемещают папки, разбивают сервисы, переименовывают пакеты и создают общие библиотеки. Старые мапы тихо портятся. Тогда селективные прогоны становятся либо слишком широкими, либо опасно узкими.

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

Быстрые проверки и следующие шаги

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

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

Начните с малого. Выберите один репозиторий с активными PR и тестовой базой, которая уже раздражает команду. Выбор тестов для сгенерированных изменений легче проверять в одном месте, чем сразу в десяти репозиториях с разными привычками, неймингом и уровнем риска.

Короткий чек‑лист полезен:

• Определите откат для неизвестных путей
• Назначьте одного владельца карты
• Отслеживайте пропущенные тесты и последующие ошибки вместе
• Пересматривайте промахи раз в месяц
• Расширяйте подход только после успешной работы в одном репозитории

Ежемесячный обзор важнее, чем кажется. Посмотрите на пропущенные случаи, тесты, которые должны были запуститься, и папки, которые теперь значат не то, что три месяца назад. Репозитории дрейфуют. Ваша карта должна двигаться вместе с ними.

Если команда копирует одну и ту же настройку везде слишком рано, она обычно копирует и те же ошибки. Один сервис может хорошо мапиться по путям файлов, а другому понадобятся теги, данные об ответственности или правила зависимостей. Заработайте доверие на одном репозитории, затем переиспользуйте только те части, которые показали себя.

Держите первую версию скучной. Простой YAML или JSON, который мапит пути на проверки, чаще всего достаточно, чтобы доказать идею. Позже можно добавить более умную логику, если простой вариант экономит время без промахов.

Если вашей команде нужна помощь с разбором правил CI или построением практичных AI‑первых рабочих процессов, Oleg Sotnikov на oleg.is работает как Fractional CTO и стартап‑советник. Он помогает малым и средним командам с инфраструктурой, автоматизацией и AI‑поддержкой разработки, когда внутренних ресурсов не хватает.