Лучший способ отследить и провести рецензирование перед фиксацией

Question

Мне было интересно, какой механизм используют люди для обеспечения и отслеживания экспертных оценок при совершении SVN.

Для каждого коммита я хочу иметь возможность отслеживать, если у людей был экспертный обзор (я не уверен, является ли хорошей идеей соблюдение правила, при котором они не могут коммитить, мне кажется, что это принудительно, поскольку существует, вероятно, действительная причина для фиксации без рецензирования), но непроверенные коммиты должны быть в состоянии отследить, чтобы перед выпуском мы могли просмотреть все эти коммиты.

Answer 1

Вы можете потребовать, чтобы каждый разработчик добавил тег комментирующего разработчика в фиксацию в фиксированном формате, например [REV: XYZ]. Это позволяет фильтровать историю. Как было упомянуто здесь, вы можете использовать ловушки предварительной фиксации вашего инструмента управления версиями исходного кода, чтобы принудительно применить это, если вам нужно.

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

Обычно нет никаких оправданий тому, что вы не выполняете проверку, когда действует это правило. В частности, «Но мне пришлось быстро исправить эту ошибку, чтобы доставить заказчику исправленную версию», не может быть оправданием, потому что разработчик с большей вероятностью совершит ошибки в спешке.

Answer 2

Этот вопрос звучит как реклама для распределенных VCS, таких как git или bzr: разработчикам необходимо часто вносить изменения, но только в свою собственную ветку, которая затем проверяется перед тем, как загружаться в центральное хранилище. 1001 *

Answer 3

Разработчики могут создавать ветки для каждого изменения (не для каждого коммита). Они могут совершать столько раз, сколько захотят в этой ветке. Однако, прежде чем изменения будут объединены в магистраль, вы можете провести рецензирование. Таким образом, ваш ствол будет содержать только проверенный код.

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

Я уже некоторое время пользуюсь контролем версий и считаю, что работать в модели ветвей (а не в магистрали) хорошо. Системы DVCS, такие как git, делают этот шаг вперед и, похоже, работают хорошо для многих людей.

Answer 4

Лично я могу часто совершать svn почти 50 раз в день, поэтому мне это не понравится;)

Я знаю, что плагин Atlassian's greenhopper для jira может быть запущен как ловушка перед фиксацией, чтобы требовать ссылку jira в коммите. Если вы используете greenhopper и для планирования задач разработки, вы можете принудительно подключить все коммиты к проблеме jira.

И даже если вы не используете greeenhopper, вы, вероятно, могли бы создать ловушку перед фиксацией, которая заставит коммит-комментарий, содержащий некоторый ссылочный номер отслеживания проблемы.

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

Answer 5

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

Я работал над такими проектами раньше, и он работает довольно хорошо. Недостатком является то, что с Subversion это означает, что имя обозревателя, а не имя разработчика, отображается в журнале. С помощью git вы можете сохранить имя разработчика, а рецензент добавляет строку «Подписано:».