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

У JetBrains есть клевая система код ревью Upsource
В моей команде 3 человека. Хочу включить в наш рабочий процесс прохождение код ревью как обязательное требования вливания кода в ветку девелоп.
Задача: все строчки кода вливаемые в ветку девелоп обязаны успешно пройти код ревью.
Я хочу узнать у тех кто использует Upsource как и когда вы создаете код ревью. Его создает тот кто написал код? Как вы следите что изменения прошли код ревью? Какие соглашения с командой вы выработали по теме код ревью?
Пожалуйста, опишите ваш рабочий процесс с этой системой.

Ответ

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

Разработчики работают в отдельных багфикс/фича бранчах. После завершения работы в Stash создается пулл-реквест, назначаются ревьюеры. В программе минимум -- это тим-лид, в программе максимум -- все члены команды.
При этом отдельно настраиваются критерии успешного код-ревью: сколько аппрувов нужно собрать. Например, если в ревьюеры назначается вся команда, можно сделать так, что для мержа достаточно аппрува двух участников. Это настройка относится к части администрирования и производится однократно.
Далее ревьюеры смотрят код, пишут комментарии. Комментарии могут быть как просто текстовыми, так и оформлены в виде задач. Текстовые комментарии никак не влияют на возможность мержа, т.е. приходится следить за ними глазами. С задачами чуть легче -- пока есть незакрытые задачи, Stash не даст замержить реквест.
После того, как набирается нужный кворум, реквест становится доступным для мержа. Но последнее слово за тим-лидом, поскольку обычно этот человек лучше всего знаком с архитектурой проекта: бывают ситуации, когда изменения валидны, ревью пройдено, но при этом с т.з. архитектуры проекта изменения не подходят. И вот тут пригождается "право вето". Правами на мерж, естественно, обладает только тим-лид. При этом Stash позволяет делать автоматический мерж после набора кворума (полезно, когда тим-лид в отпуске :)).
При этом отдельно в процесс ревью можно подключать статический анализатор кода. Все проблемы, найденные им, высвечиваются в реквесте и тоже должны быть исправлены. Однако на мой взгляд статический анализатор имеет смысл подключить уже на этапе билда. Есть ошибки -- нет билда.

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

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