Автоматический обзор пул-реквестов подключается после интеграции с системой контроля версий и работает с основными провайдерами, включая варианты, развёрнутые внутри компании. Уровень тарифа определяет охват: личный обычно смотрит только ваши собственные изменения, командный позволяет включить репозитории для всех участников и задать списки тех, кому обзор нужен и не нужен. Это первое решение, которое стоит принять осознанно: обзор всего подряд быстро превращается в поток, который перестают читать.
Самое важное, что стоит понять до внедрения, - как читается результат проверки. Успех означает, что нет ни новых находок, ни неразрешённых старых замечаний. Нейтральный результат появляется, когда находки есть, когда прогон был отменён или заменён более свежим, а также при внутренней ошибке - и именно нейтральный является поведением по умолчанию при наличии находок. Провал возникает только тогда, когда неразрешённые находки есть и включено соответствующее поведение. Три разные причины дают один и тот же нейтральный результат, и по нему одному отличить находки от сбоя нельзя.
Отсюда следует вывод, который экономит недели непонимания. Пока настройка провала не включена, проверка не блокирует слияние сама по себе - она информирует. Команда, которая рассчитывает на автоматическую блокировку, но не включила её, живёт с ложным ощущением защиты: замечания появляются, а слияния идут своим чередом. Проверить это стоит один раз, специально: создать тестовый пул-реквест с заведомой находкой и посмотреть, что произойдёт с кнопкой слияния. Ответ, полученный экспериментом, надёжнее ответа, полученного из настроек.
Полезно один раз свести значения результата в таблицу. Ниже такая карта. Она же снимает вопрос про отсутствующий статус пропуска: такого заключения обзор не публикует, и если вы его ждёте в своей автоматизации, вы ждёте того, чего не будет. Ветка кода, написанная под несуществующее состояние, не выполнится ни разу и будет годами выглядеть как забота о полноте.
| Результат | Что означает |
|---|---|
| Успех | Нет находок и нет неразрешённых прежних замечаний |
| Нейтральный | Есть находки, прогон отменён или заменён, либо внутренняя ошибка; поведение по умолчанию при находках |
| Провал | Есть неразрешённые находки и включено соответствующее поведение |
|---|
| Пропуск | Такой результат обзор не публикует |
|---|
У корпоративного программного интерфейса есть отдельная запись для запуска обзора, и у неё есть ограничения по частоте и по правам. Отдельно стоит режим пробного прогона: он выполняет анализ без последствий в системе контроля версий - не оставляет комментариев и не публикует статус. Но важно понимать, что пробный прогон не эфемерный: находки сохраняются, и он тарифицируется. Своё отдельное ограничение частоты у него тоже есть, и оно строже обычного.
Это типичный пример свойства, которое легко принять за очевидное и ошибиться. Слово пробный обычно означает бесплатно и без следов; здесь оно означает без побочных эффектов в репозитории. Разница проявляется в счёте и в накопленных находках, и лучше узнать о ней из документации, чем из отчёта о расходах. Тот же разбор полезно проделать с каждым режимом, который называется словом из повседневного языка: проверить, что именно он не делает, а не додумывать по названию.
Блокировка слияния - вообще не свойство обзора, а свойство провайдера. Обзор публикует статус проверки; решение о том, обязателен ли этот статус для слияния, принимается защитой веток на стороне системы контроля версий. Значит, настроек две, и они должны совпасть: поведение провала на стороне обзора и требование этой проверки в правилах ветки. Включённая одна без другой даёт два разных знакомых сюрприза - либо провал, который никого не останавливает, либо обязательную проверку, которая никогда не проваливается. Эти два механизма стоит развести в голове раз и навсегда: один производит сигнал, другой решает, что с ним делать.
Внедрять обзор разумно так же, как автоматизацию: постепенно и с измерением. Начните с нескольких репозиториев, где есть кому разбирать находки, и смотрите на одну величину - долю замечаний, по которым что-то сделали. Если она держится высокой, охват можно расширять. Если растёт доля закрытых без изменений, это не значит, что обзор плохой: чаще это значит, что он смотрит на код, для которого его правила не настроены. И если обзором управляют программно, полезно с самого начала ограничить область действия ключа и хранить идентификатор запроса - иначе разбирать, почему прогон повёл себя не так, придётся по косвенным признакам.
Инженерный вывод простой: автоматический обзор - это сигнал, который вы встраиваете в свой процесс, а не готовый процесс. Решите заранее, блокирует ли он слияние, кто разбирает находки, что считается разрешённым замечанием и как это связано с защитой веток на стороне провайдера. Без этих решений он превращается в поток комментариев, который через месяц начинают пролистывать, а ещё через месяц отключают.
Типичные провалы предсказуемы. Ждать блокировки слияния без включённой настройки провала. Считать пробный прогон бесплатным и бесследным. Ориентироваться на несуществующий статус пропуска. Развести настройку провала и защиту веток так, что они не совпадают. И внедрить обзор без владельца находок - тогда замечания копятся, а разрешать их некому.