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

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

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

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

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

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

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

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

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

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

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

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

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

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

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