Процесс публикации тестовых версий продукта для внутреннего использования и ведения списка «что в этой версии» при использовании Mercurial?

Question

Мне нужны конкретные идеи для этого.

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

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

По сути, когда программист проверяет окончательное изменение, которое фиксирует случай в нашей системе управления делами, Visual Studio отвечает, с каким номером набора изменений этостал, и затем программист прикрепляет это к случаю, который в основном гласит: «Если вы используете версию нашего продукта с номером последней версии, это значение или выше, то у вас есть все изменения в этой версии».

Однако, с Mercurial, который не работает, так как номера ревизий могут и будут меняться при поступлении коммитов из разных ветвей.

Поэтому мне интересно, как я могу получить что-то подобное.

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

В принципе, мне нужно, чтобы кто-то тестировал, чтобы увидеть, имеет ли версия, на которой он тестирует, изменения, связанные с тест-кейсом, или нет.

Я рассматривал следующее:

1. Программист фиксирует и получает хэш набора изменений
2. Программист прикрепляет это к кейсу в нашем трекере кейсов
3. Процесс сборки должен пометить (неMercurial) версия, чтобы она знала, из какого набора изменений она была построена из
4. Я должен упростить получение хеша набора изменений, из которого был построен наш продукт, найдите его в журнале измененийхранилище, используемое для нашей сборочной машины, а затем выяснить, совпадает ли набор изменений продукта с каждым случаем в списке тестов или является его предком.

Итак, у меня два вопроса:

1. Это выполнимый подход?Я не против создания веб-приложения, которое облегчает работу с ним
2. Кто-нибудь знает об альтернативном процессе, который может мне помочь?Я смотрел на тегирование, но кажется, что тегирование в конечном итоге добавляет давление слияния, это то, что я хочу?(т.е. добавление / перемещение тега заканчивается как коммит, который необходимо объединить с остальной частью системы)
3. Есть ли что-нибудь, что могло бы помочь мне из коробки, то есть иметькто-то сделал или знает, что-то подобное уже?
4. Есть еще идеи?

Answer 1

И код Bitbucket, и код Google поддерживают временную шкалу ветвления, которая наглядно показывает, что было объединено, кто и когда. Я подозреваю, что это может быть то, что вы хотите сделать: это очень простой способ решить проблему 4.

Как они это делают, я не знаю, но инструменты там. BitBucket предлагает коммерческий код хостинга.

Answer 2

Правильно ли говорить, что вы ищете легкий процесс пометки, связанный с вашим процессом сборки?

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

У многих систем управления коробками есть это - Fogbugz , например.