Автоматический линтинг кода в CI/CD: ESLint, Pylint, golangci-lint

Автоматический линтинг в конвейере: где ломается качество

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

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

Ручные замечания на ревью при этом почти всегда про одно и то же: форматирование, именование, порядок импортов, забытый отладочный вывод. Ревьюер разбирает стиль вместо логики, а спор о вкусах занимает место обсуждения архитектуры. Часть замечаний не доходит вовсе — правило нигде не зафиксировано, и в следующей ветке всё повторяется.

Причина не в дисциплине, а в настройке. Линтер (ESLint, Pylint или golangci-lint — по стеку проекта) запускается по всему дереву, на унаследованном коде висит несколько тысяч предупреждений, уровень строгости выставлен в предупреждение вместо ошибки — и десятое из сотни никто не замечает. Разбираем, как это закрывается: перенос проверки в начало прохода, строгий уровень для новых изменений и отдельный режим для исторического кода.

Что даёт автоматический линтинг: эффект на сборку

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

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

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

Нагрузка на ревью снижается потому, что ревьюер перестаёт быть фильтром форматирования. Споры о длине строк, порядке импортов и точках с запятой уходят из комментариев: правила заданы в конфигурации вроде ESLint, Pylint или golangci-lint и применены автоматически. Единый стиль кода перестаёт быть предметом устных договорённостей — новый инженер получает его прямо из репозитория.

Форматы проверки кода: локально, в сборке, на сервере

Одна и та же проверка может срабатывать в четырёх точках процесса, и это не взаимоисключающие варианты: практика — выбрать обязательную точку и добавить к ней дешёвые подстраховки. Ниже — по колонкам «когда подходит» и «ограничения», чтобы сопоставить режим с размером репозитория и ритмом релизов.

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

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

Как мы выстраиваем проверки: порядок работ

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

1. Аудит кодовой базы. Считаем объём по языкам и срабатывания по каждому правилу ESLint, Pylint и golangci-lint на актуальной ветке. На выходе — перечень массовых нарушений и файлов, которые правим до включения строгого режима.

2. Набор правил. Делим правила на три группы: ловящие реальные дефекты — включаем сразу; стилевые — по мере правок; спорные — в исключения с пометкой причины. Конфигурация остаётся читаемой, а не свалкой.

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

4. Запуск в CI/CD. Линтер проверяет изменённые строки, а не весь репозиторий: сборка не удлиняется, но новое несоответствие не проходит. Локальный прогон до отправки даёт ту же проверку за секунды.

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

6. Передача регламента. Отдаём документ: какие правила включены и почему, как добавить исключение, кто утверждает правки конфигурации. Разбираем на коде команды — так регламент читают, а не складывают в архив.

Что команда получает на руки после внедрения проверок

Внедрение проверок заканчивается не «зелёной» сборкой, а набором артефактов, которые команда ведёт дальше сама. Конфигурации и общие наборы правил лежат в репозитории рядом с кодом, поэтому новый сервис подключается к автоматическому линтингу копированием, а не переговорами с инфраструктурной командой. Ниже — что именно остаётся у вас на руках.

• Конфигурации правил по каждому языку с комментариями: что правило ловит, почему включено, как оформить ложное срабатывание.
• Общие наборы для репозиториев: базовый профиль как обязательный минимум и подключаемые модули под сервисы, интерфейс и инфраструктурные описания. Наследование вместо копирования — правило меняется в одном месте.
• Схема запуска проверок: хук перед коммитом на изменённых файлах, полный набор при слиянии ветки как блокирующий шаг, ночной прогон по всему коду — новые правила не рушат старые файлы внезапно.
• Порядок исключений: файл подавлений с обоснованием, владельцем и сроком пересмотра у каждой записи. Временное отключение правила отличается от постоянного и видно в отчёте.
• Документация по качеству кода: как добавить или понизить правило, где смотреть отчёт, что делать при красной сборке.
• Регламент реакции на нарушения: что правится в текущей задаче, что уходит отдельным пунктом, когда подключается эскалация. Правило, которое все обходят, честно отключается или переводится в предупреждение.
• Набор метрик: доля проверенных путей, число подавлений на репозиторий, время прогона — по ним видно, где набор начал мешать, а не помогать.

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

Кейс: единый шлюз качества в монорепозитории

Монорепозиторий на несколько десятков пакетов: часть правил лежала в локальных конфигурациях, часть — в отдельных репозиториях, подключённых как зависимости. Наборы расходились — ESLint, Pylint и golangci-lint запускались с разными уровнями строгости. Один и тот же фрагмент проходил проверку в одном пакете и ронял сборку в соседнем.

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

Как устроили единый шлюз

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

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

Чем проверка в сборке отличается от проверки в редакторе

Локальная проверка в редакторе отвечает на вопрос «не ошибся ли я прямо сейчас»: линтер срабатывает на сохранении файла, подсвечивает проблему через доли секунды и даёт ту скорость обратной связи, ради которой его ставят. Но гарантий она не даёт — расширение может быть отключено, набор правил отличаться от командного, а часть файлов в этой сессии вообще не открывалась.

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

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

Дублирование правил ломает схему. Если конфигурация в редакторе и в шлюзе живёт раздельно, разработчик узнаёт о нарушении только на этапе слияния, а версии правил расходятся. Поэтому набор подключается из одного файла, который читают и ESLint-подобные инструменты, и шаг сборки: локально — предупреждения, в шлюзе — ошибка.

Технические сомнения: вопросы о правилах и поддержке

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

Не замедлит ли автоматический линтинг сборку?

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

Кто поддержит набор правил после передачи проекта?

Конфиг лежит в репозитории рядом с кодом и меняется обычным запросом на слияние — с проверкой вторым инженером и историей, кто и зачем включил правило. Передаём документацию: назначение каждого правила, из-за какого сбоя оно появилось, как добавить своё и как снять шум. Ужесточение идёт порциями: раз в две недели включаем одну-две группы правил, смотрим долю падений сборки и откатываем, если предупреждений больше, чем реальных дефектов.

Обсудим задачу: что нужно знать перед стартом

Оценка получается точной, когда мы видим проект, а не его описание в двух строках. Первый разговор занимает 30–40 минут и идёт по делу: разбираем репозитории, текущие проверки и то, что мешает им работать. Ниже — вводные, после которых мы возвращаемся с оценкой и планом работ.

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

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