Организация процесса код ревью для небольшой команды с помощью Upsource

#инспекция_кода

У JetBrains есть клевая система код ревью Upsource.

В моей команде 3 человека. Хочу включить в наш рабочий процесс прохождение код ревью
как обязательное требования вливания кода в ветку девелоп. 

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

Я хочу узнать у тех кто использует Upsource как и когда вы создаете код ревью. Его
создает тот кто написал код? Как вы следите что изменения прошли код ревью? Какие соглашения
с командой вы выработали по теме код ревью?

Пожалуйста, опишите ваш рабочий процесс с этой системой.
    

Ответы

Ответ 1

С Upsource я не работал, могу описать процесс на примере Atlassian Stash (недавно
переименован в Bitbucker Server). Судя по тому, что я быстренько прочитал об Upsource,
там есть аналогичная функциональность. Все описанное справедливо для использования
git flow/github flow (судя по вашим предыдущим вопросам вы используете гит).



Разработчики работают в отдельных багфикс/фича бранчах. После завершения работы в
Stash создается пулл-реквест, назначаются ревьюеры. В программе минимум -- это тим-лид,
в программе максимум -- все члены команды.

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

Далее ревьюеры смотрят код, пишут комментарии. Комментарии могут быть как просто
текстовыми, так и оформлены в виде задач. Текстовые комментарии никак не влияют на
возможность мержа, т.е. приходится следить за ними глазами. С задачами чуть легче --
пока есть незакрытые задачи, Stash не даст замержить реквест.

После того, как набирается нужный кворум, реквест становится доступным для мержа.
Но последнее слово за тим-лидом, поскольку обычно этот человек лучше всего знаком с
архитектурой проекта: бывают ситуации, когда изменения валидны, ревью пройдено, но
при этом с т.з. архитектуры проекта изменения не подходят. И вот тут пригождается "право
вето". Правами на мерж, естественно, обладает только тим-лид. При этом Stash позволяет
делать автоматический мерж после набора кворума (полезно, когда тим-лид в отпуске :)).

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



Общие соображения на эту тему такие:


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




Теперь конкретные ответы на вопросы.


  Его создает тот кто написал код?


Да.


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


Это могут быть как автоматические ограничения (на примере задач в Stash), так и дополнительный
"ручной" контроль со стороны человека, который занимается мержем. Ну и дисциплина самих
разработчиков: если Вася сообщил о проблеме в коде, он не должен тут же ставить аппрув.