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