Рабочий процесс ветвления на функцию с использованием Mercurial

Question

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

Я вижу этот процесс так: 1. сделать ветку релиза (r-b) по умолчанию (транк) 2. сделать ветвь объекта (f-b) по умолчанию (транк)

Когда разработчик думает, что его функция готова, он может объединить f-b с r-b. Когда пришло время перейти к QA, мы объединяем все готовые f-b с r-b и создаем релиз для наших QA.

Вопросы:

1. Когда QA находит ошибку, разработчик должен изменить свой f-b и снова объединить его с r-b. Означает ли это, что разработчик просто переключается на свой f-b и начинает исправлять ошибку, а затем снова выполняет простое слияние f-b с r-b?

2. Когда релиз проходит QA, он переходит к PROD - как мы можем заморозить изменения? "hg tag" - хороший выбор, но кто-то может обновить тег, если он действительно этого хочет.

Спасибо

Answer 1

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

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

2) Я использовал тег Hg.Вы правы в том, что кто-то меняет перемещение тега, если он действительно этого хочет, но теги версионны, и вы можете установить хуки в главном репозитории hg, чтобы выдавать оповещения, если тег перемещен.Я действительно не буду беспокоиться о перемещении тегов, если вы не можете доверять своим разработчикам, в этом случае вы облажались.

Answer 2

Ответ на ваш первый вопрос - «да».

Лучший способ заморозить релиз - это иметь отдельный клон релиза, в который только менеджер релизов может отправлять / извлекать наборы изменений. То, что вы используете ветки, не означает, что нескольким клонам не место в вашем рабочем процессе. Наличие клона, который QA проводит финальное предполетное тестирование, на котором разработчики не могут вносить изменения, создает отличный межсетевой экран.

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