Рекомендуемый процесс для обзоров кода с Mercurial

18

Обычно мы использовали Perforce и SmartBear's Code Collaborator, Big Corpи теперь мы также собираемся использовать Mercurial для определенных проектов.

Code Collaborator поддерживает Mercurial (мы используем версию 5), и я пытаюсь определить, когда лучшее время (во время фиксации / отправки на сервер) процесс является наилучшим / эффективным временем для проверки кода

Благодарность

cbrulak
источник
Вы, вероятно, должны разделить два вопроса. (a) принадлежит здесь, но (b), вероятно, будет принадлежать стеку или потере сервера
blueberryfields
Спасибо @blueberryfields. я на самом деле исправил проблему, проблема была в том, что файл bin / hg.cmd был в пути, а не в exe.
cbrulak

Ответы:

22

На самом деле, мы недавно прошли почти то же самое в моей компании. Вот что мы сделали:

  • Мы храним центральную окончательную копию всех наших репозиториев на одном сервере. Когда разработчики хотят «проверить» код, они идут на этот сервер и клонируют из репозиториев там. Аналогичным образом, когда цикл разработки завершен, код также помещается в соответствующий репозиторий.

  • Мы отделяем стабильные репозитории от репозиториев разработки . Мы требуем, чтобы код был проверен, прежде чем он будет помещен в стабильный репозиторий. (Это важно, потому что мы также требуем, чтобы наши стабильные репозитории содержали код, который в настоящее время запущен в производство, отличающийся только ожидающими продвижения кода.)

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

  1. Разработчик инициирует переход в стабильный репозиторий (да, это действительно первый шаг)
  2. Хук запускается и захватывает список всех наборов изменений, включенных в транзакцию (запустив журнал HG). Затем он запрашивает базу данных, которую мы создали, чтобы увидеть, были ли эти наборы изменений включены в обзор кода. (Таблица сопоставляет хэш набора изменений с идентификатором проверки кода).
    • Если это первый раз, когда какой-либо из этих наборов изменений был замечен, то мы создаем новый Code Review (используя командную строку Code Collaborator), а затем записываем эти наборы изменений в базу данных с идентификатором этого обзора кода.
    • Если мы видели некоторые (но не все) наборы изменений, мы запускаем команду (Code Collaborator), чтобы присоединить новые наборы изменений к существующему обзору и записать эти новые наборы изменений в базу данных.
    • Если все изменения были найдены в базе данных (то есть все они были добавлены в проверку кода), то мы проверяем, что статус проверки кода выполнен. Однако, если появились какие-либо новые наборы изменений (или проверка кода не завершена), ловушка завершается с ненулевым кодом состояния (что приводит к откату транзакции Mercurial) и выводит дружественное сообщение о стандартной ошибке, объясняя разработчику что проверка кода должна быть завершена.

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

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

Райан
источник
Не могли бы вы объяснить свое решение для проверки вашей стабильной среды до проверки кода? На мой взгляд, стабильный, кажется, неправильно.
Иордания
1
Вероятно, из ответа не было ясно, но он фактически не попадает в репозиторий, если все изменения не были добавлены к обзору кода и проверка не завершена. Если ловушка завершается с ненулевым кодом выхода, Mercurial откатывает все изменения, которые были переданы. Таким образом, этот конкретный хук предоставляет очень удобное место для того, чтобы не только получить различия в обзоре, но и обеспечить его выполнение до того, как изменения будут допущены в хранилище.
Райан
1
Вау. Могу ли я прийти работать на вас?
Богатое
@Ryan - Как мы реализуем хук pretxnchangegroup, ссылка, которую вы предоставляете, не дает подробного объяснения того, как она может быть реализована, не дает того шаблона функции, которому мы должны следовать, куда поставить хук. У меня нет опыта работы с питоном. Пожалуйста, не могли бы вы перенаправить меня на правильный источник или шаблон для ловушки pretxnchangegroup. Та
Простое решение
2

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

Если вы хотите делать обзоры после отправки, идеальный рабочий процесс сильно зависит от структуры вашего хранилища. Например, давайте предположим, что структура репозитория выглядит так, как описано в этой статье о макетах репозитория Git . В этом случае вы можете просмотреть изменения, которые объединяются в develop. Отдельные коммиты в функциональных ветках могут не иметь смысла просматривать. Очевидно, что все hotfixesтакже должны быть рассмотрены вместе с объединением в master.

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

Что касается б), единственное, что я хотел бы предложить, - это напрямую связаться со службой поддержки SmartBear (support@smartbear.com). Мы (да, я работаю на SmartBear) будем рады помочь вам решить ваши проблемы с путями, но в этом вопросе недостаточно информации, чтобы решить вашу проблему. Обычный процесс - просто запустить установщик, и все работает. Очевидно, что-то пошло не так в этом процессе.

Брэндон Дюретт
источник