Рекомендований процес для огляду коду з допомогою mercurial

Зазвичай ми використовували Perforce та SmartBear Code Collaborator, Big Corpі тепер також будемо використовувати Mercurial для певних проектів.

Підтримка Code Collaborator Mercurial (ми використовуємо версію 5), і я намагаюся визначити, коли найкращий час (під час фіксації / натискання на сервер) найкращий / ефективний час для перегляду коду

Спасибі

code-reviews mercurial

— cbrulak
джерело

Вам, мабуть, слід розділити два питання. (а) належить тут, але (б), ймовірно, належав би до stackoverflow або serverfault

— blueberryfields

Дякуємо @blueberryfields. Я фактично виправив проблему, проблема полягала в тому, що файл bin / hg.cmd перебуває на шляху, а не в exe.

— cbrulak

Відповіді:

Ми фактично пережили майже таку саму річ у моїй компанії нещодавно. Ось що ми зробили:

Ми зберігаємо центральну остаточну копію всіх наших сховищ на одному сервері. Коли розробники хочуть "перевірити" код, вони переходять на цей сервер і клонують із тамтешніх сховищ. Так само, коли цикл розробки закінчується, код також висувається у відповідне сховище.
Ми відокремлюємо стабільні сховища від сховищ розробки . Ми вимагаємо переглянути цей код до того, як він буде висунутий у стабільне сховище. (Це важливо, тому що ми також вимагаємо, щоб наші стабільні сховища містили код, який наразі працює у виробництві, і відрізняється лише відкладеними рекламними кодами.)

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

Розробник ініціює поштовх до стабільного сховища (так, це дійсно перший крок)
Гак запускається та захоплює список усіх наборів змін, включених до транзакції (за допомогою журналу HG). Потім він запитує базу даних, яку ми створили, щоб побачити, чи включені ці набори змін в огляд коду. (Таблиця відповідає хешу набору змін ідентифікатору перегляду коду).
- Якщо вперше було помічено будь-який із цих наборів змін, тоді ми створюємо новий Огляд коду (використовуючи командний рядок Кола Collaborator), а потім записуємо ці набори змін у базу даних з ідентифікатором цього коду огляду.
- Якщо ми бачили деякі (але не всі) набори змін, ми запускаємо команду (Кола Collaborator), щоб приєднати нові набори змін до існуючого огляду та записати ці нові набори змін у базу даних.
- Якщо всі зміни були знайдені в базі даних (тобто всі вони були додані до огляду коду), то ми перевіряємо, чи перегляд коду завершено. Однак якщо були якісь нові набори змін (або огляд коду не завершено), гак завершується з ненульовим кодом статусу (змушує Mercurial повернути транзакцію) і видає дружнє повідомлення про стандартну помилку, що пояснює розробнику що огляд коду потрібно закінчити.

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

Примітка. Це досить простий процес (і порівняно новий для нас), тому він може працювати не для всіх, і можуть виникнути помилки в дизайні, до яких ми ще не стикалися. Але поки що це спрацювало досить непогано.

— Райан
джерело

Ви б пояснили своє рішення щодо перевірки вашого стабільного середовища перед переглядом коду? Мені стабільний здається помилковим.

— Йорданія

З відповіді це, мабуть, не було зрозуміло, але він насправді не вносив його у сховище, якщо всі зміни не були додані до огляду коду та огляду не завершено. Якщо гачок закінчується з ненульовим кодом виходу, Mercurial відкочує всі зміни, які були натиснуті. Таким чином, саме цей гак забезпечує дуже зручне місце не лише для отримання розбіжностей для огляду, а й для примусового огляду до внесення змін у сховище.

— Райан

Ого. Чи можу я прийти працювати на вас?

— Багатий

@Ryan - Як ми реалізуємо гачок pretxnchangegroup, надане вами посилання не дає детальних пояснень щодо того, як це можна реалізувати, не дає вибору шаблону функцій, за яким ми повинні слідувати, куди слід надіти гачок. У мене немає досвіду пітонів. Будь ласка, ви можете перенаправити мене до правильного джерела або шаблону для гачка pretxnchangegroup. Ta

— Simple-Solution

Це залежить від того, як у вас є структура сховища і що ви намагаєтеся досягти. Ми вважаємо за краще робити "попередньо здійснювати" огляди, що у світі DVCS насправді означає "попередній натиск". DVCS приємніші в цьому середовищі (порівняно з традиційними SCM), оскільки вони мають вбудований функціонал для збереження ваших локальних змін та повернення робочої області, щоб ви могли працювати над чимось іншим.

Якщо ви хочете робити пост-поштові огляди, ідеальний робочий процес значною мірою залежить від вашої структури сховища. Наприклад, припустимо структуру сховища, схожу на описану в цій статті про макети репозиторію Git . У цьому випадку ви можете переглянути зміни, до яких об’єднано develop. Окремі зобов’язання щодо функціональних гілок можуть не мати сенсу переглядати. Очевидно, що все hotfixesтакож слід переглянути, разом із злиттями в master.

Якщо замість цього ви маєте єдину гілку інтеграції, де люди безпосередньо заїжджають, ви хочете переглянути всі поштовхи до цієї гілки. Це, мабуть, трохи менш ефективно, але все-таки може працювати. У цьому середовищі вам доведеться переконатися, що всі зміни, які були натиснуті, переглянуті перед тим, як скоротити випуск. Це може бути складніше.

Що стосується б), я б тільки запропонував - надіслати електронною поштою підтримку SmartBear (support@smartbear.com) безпосередньо. Ми (так, я працюю в SmartBear) із задоволенням допоможемо вам розібратися зі своїми проблемами, але в цьому питанні недостатньо інформації для вирішення вашої проблеми. Нормальний процес - це просто запустити інсталятор і все просто працює. Мабуть, щось пішло не так у тому процесі.

— Брендон Дюрет
джерело