Инструменты и интеграции

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

Что именно способны проверить анализаторы и линтеры — в теме Автоматизация курса Pro. Здесь — про встраивание в процесс.

Главная мысль урока: любое правило, которое команда согласовала, надо перенести в настройки. Иначе оно живёт в чьей-то памяти и работает избирательно.

Пункт про администраторов важнее, чем кажется: если правила не распространяются на тимлида, они читаются как необязательные. «Include administrators» — одна галочка, меняющая восприятие всего процесса.

Порядок строк значим: применяется последнее совпадение, а не первое. Это источник неожиданностей — правило * в конце файла отменит все предыдущие.

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

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

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

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

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

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

Отдельно про скорость. Обязательные проверки определяют минимальное время до мержа. Если CI идёт 25 минут, цикл из трёх раундов — это больше часа только ожидания. Что помогает: параллельные задачи вместо последовательных, быстрые проверки первыми (линтер за 10 секунд отсеет часть PR до запуска тестов), кэш зависимостей, запуск тестов только по затронутым областям на монорепозитории.

Проверьте себя. Сколько идёт ваш CI на PR? Сколько из этого времени — установка зависимостей?

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

Автоматический комментарий работает, пока его читают. Порог наступает быстрее, чем кажется.

Что делает бота полезным:

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

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

Проверьте себя. Посмотрите последние десять PR: сколько комментариев от ботов и сколько от людей? Соотношение больше трёх к одному — повод сокращать.

Частая ошибка. Оценивать бота по числу найденного. Оценивать надо по доле исправленного.

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

Работающее правило: уведомление отправляется конкретному человеку и требует от него действия.

Последняя строка — самая полезная. Уведомление о каждом открытом PR не требует действия ни от кого конкретно и потому только приучает игнорировать канал.

Отдельный механизм, который стоит внедрить: ежедневная сводка PR, ждущих дольше SLA, с именами. Не как способ давления, а потому что забывают все, а список видят все.

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

Частая ошибка. Отправлять всё в общий канал вместо личных сообщений. Уведомление без адресата — не уведомление.

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

Черновики PR. PR, открытый как черновик, не запрашивает ревью, но показывает работу и запускает CI. Снимает потребность в комментариях «пока не смотри».

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

Стек PR. Второй PR открывается в ветку первого. Позволяет не ждать мержа предыдущего и разбивать работу без простоя.

Автомерж после проверок. Автор ставит галочку, PR мержится сам, когда CI зелёный и одобрения получены. Убирает ожидание «кто нажмёт кнопку».

Автоматическое переназначение. Если ревьюер не ответил в срок, запрос уходит следующему. Решает проблему отпусков без ручного вмешательства.

Проверьте себя. Какие из пяти пунктов используются в вашей команде?

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

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

Что видит опытный участник. Каждая настройка по отдельности разумна. Вместе они дают паралич.

CI идёт 25 минут, из них 4 — установка зависимостей без кэша, 18 — последовательные тесты. При трёх раундах это 75 минут чистого ожидания.

Dismiss stale approvals on new commits в сочетании с двумя обязательными одобрениями и медленным CI даёт замкнутый круг: автор правит опечатку, оба одобрения сбрасываются, надо снова искать двух людей и снова ждать 25 минут. Именно эта комбинация — главная причина роста до трёх дней.

Require conversation resolution делает блокирующим каждый комментарий, включая nit и info от reviewdog. А reviewdog настроен на level: info и filter_mode: nofilter — то есть комментирует всё подряд, включая строки, которых автор не касался. Получается: бот оставил сорок информационных замечаний по чужому коду, и все сорок надо закрыть руками, чтобы смочь смержить.

Пять обязательных проверок, среди которых license-check и size-limit — они падают по причинам, не связанным с качеством изменения, и потому не должны блокировать.

Include administrators выключено: правила не распространяются на тех, чьё поведение задаёт норму.

В Slack девять типов событий, включая commit pushed и CI started. Канал нечитаем, поэтому выключен, — и вместе с ним потеряны уведомления о падении основной ветки.

Комментарии к конфигурации:

Чем закончилось.

Через месяц: время до мержа — 5 часов, комментариев от ботов на PR — 2 вместо 40, канал #dev-alerts читают, потому что там раз в неделю появляется что-то важное.

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

Какие числа смотреть, чтобы понять, работает ли настроенное, — Метрики процесса. Что именно проверяют анализаторы — Автоматизация. Процессные договорённости, которые эти настройки закрепляют, — Процесс и workflow.