Mercurial: Указывает, что ветка прошла тестирование?

Я работаю над созданием рабочего процесса в своей компании, если мы перейдем на DVCS (скорее всего, Mercurial). Одна из вещей, которые я хотел бы сделать, это иметь репозиторий для QA. Идея заключается в том, что каждый разработчик работает над веткой, и когда они закончат работу, ветка будет передана QA. Оттуда команда тестирования может провести тестирование и сообщить о любых ошибках. Как только ветвь будет полностью протестирована и принята, она будет отправлена ​​в промежуточный репозиторий, где произойдет слияние с основной веткой перед отправкой в ​​​​центральный репозиторий.

Это может работать довольно легко, если каждый просто каким-то образом сообщает о статусе своей работы, но я знаю, что это не всегда происходит так, как вам хотелось бы. Что меня беспокоит, так это то, что ветки в репозитории QA ждут, но никто не знает, ожидает ли он тестирования, тестирования в настоящее время, ожидания исправлений, ожидания отправки в промежуточную область и т. д. Итак, я ищу идеи. как статус можно добавить в ветку? Также было бы хорошо сделать это таким образом, чтобы мы могли использовать хуки, чтобы также уведомлять людей об изменениях в статусе.

Любые идеи были бы хорошы.


version-control workflow dvcs mercurial
person DaveJohnston    schedule 18.01.2011    source источник

Ответы (5)


arrow_upward
5
arrow_downward

К сожалению, я думаю, что вам нужна другая система, чтобы отслеживать эту часть вашего рабочего процесса.

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

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

Я бы определенно попытался использовать систему отслеживания ошибок, где вы можете каким-то образом интегрировать историю репозитория, даже если это просто связать проблему в системе с ее набором изменений.

Я заметил ваш комментарий о том, что вы не получаете поддержки при покупке Kiln, но есть и другие системы, которые вы должны интегрировать, чтобы получить нечто подобное.

Я бы очень сопротивлялся попыткам заставить Mercurial служить чему-то, для чего он не был создан, попытка использовать теги для этого с треском провалилась бы, а закладки доставили бы вам проблемы, как вы уже заметили.

Так что еще раз, попробуйте найти отдельную систему для отслеживания статуса вопросов и ответов.

person Lasse V. Karlsen    schedule 19.01.2011

arrow_upward
1
arrow_downward

Одним из простых способов может быть сохранение файла метаданных в корневой папке репозитория с именем .teststatus или чем-то подобным, который выглядит так:

# branch-name, last passed revision
default, 0123456789ab
stable, 0123456789ac
bobs-dev-branch, 0123456789ad
marys-dev-branch, none

Использование тегов или закладок здесь будет выглядеть как злоупотребление. Вы не можете использовать один и тот же тег в разных ветвях (например, passed должен быть stable-passed), и теги, как правило, не перемещаются. Закладки, с другой стороны, предназначены для перемещения, но у вас все еще есть проблемы с пространством имен веток.

person Matt    schedule 18.01.2011
comment
Для этого есть расширение, и его достаточно просто адаптировать для конкретного варианта использования OP: mercurial. selenic.com/wiki/FileReviewExtension и bitbucket.org/romanz/ hgcr/src/bfd3a7d6dced/filereview.py - person TryPyPy; 21.01.2011

arrow_upward
0
arrow_downward

Джоэл Спольски, один из основателей этого сайта, создает программу под названием FogBugz, которая интегрирована с Mercurial и позволяет легко отслеживать статус каждого.

person Summer    schedule 18.01.2011
comment
К сожалению, заставить мою компанию заплатить за FogBugz было бы все равно, что вытащить кровь из камня. Но вы натолкнули меня на мысль, что мы можем просто использовать Bugzilla для отслеживания статуса. Каждая ветка уже должна быть связана с ошибкой (независимо от того, является ли она на самом деле дефектом или функцией и т. д.), чтобы мы могли добавить дополнительное поле в Bugzilla, указывающее статус. - person DaveJohnston; 19.01.2011

arrow_upward
0
arrow_downward

Я не совсем уверен, как работает ваш рабочий процесс, но вот несколько идей:

  1. Теги.
  2. Используйте именованные ветки и закрыть ветку при проверке. Введите hg branches, чтобы увидеть, какие ветки все еще находятся на рассмотрении.

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

person Kyle Heironimus    schedule 18.01.2011
comment
Я думал о тегах, я просто не был уверен, что можно хранить так много тегов. Будет ли установлен тег на кончике ветки, указывающий ее статус, а затем обновляться при каждом изменении статуса? Или вам придется создавать новый тег каждый раз, когда статус меняется? Можем ли мы перейти из репозитория QA в промежуточный репозиторий (где происходит слияние) без тега, идущего вместе с ним (т.е. тег существует только в репозитории QA)? - person DaveJohnston; 18.01.2011
comment
Что на самом деле происходит с веткой, когда она закрывается? Может еще обновить? Можно ли его хотя бы слить обратно в основную ветку? Или закрытие выполняется как часть слияния (в этом случае, я думаю, слияние уже является признаком того, что ветвь была протестирована). - person DaveJohnston; 18.01.2011
comment
Основной эффект закрытия состоит в том, что он удаляется из списков ветвей и головок. Вы по-прежнему можете объединить ветку, обновить ее и даже снова зафиксировать ее, что приведет к повторному открытию ветки. - person Matt; 19.01.2011
comment
Re:tags — Да, теги будут сидеть повсюду. Они хороши для некоторых вещей, но имеют тенденцию загромождать ваш репозиторий, если используются слишком часто. - person Kyle Heironimus; 19.01.2011
comment
FWIW, я действительно не очень хорошо отношусь ни к одному из моих предложений. Мне нравится то, что вы пытаетесь сделать, но не могу придумать хорошего решения. Если бы я был на вашем месте, думаю, я бы немного больше покопался с тегами и тем, как вы можете их удалить, прежде чем отправлять их в другой репозиторий. - person Kyle Heironimus; 19.01.2011

arrow_upward
0
arrow_downward

Зачем разработчику помещать что-то в репозиторий QA, если оно не готово для QA? Я думаю, что отправка наборов изменений в репозиторий, назначенный QA, должна быть сигналом того, что функция готова к тестированию.

Добавление ветвей путем клонирования — мой любимый подход.

person Rob Sobers    schedule 19.01.2011
comment
Да, это довольно очевидно, но не единственный вариант использования. Что происходит, когда тестер обнаруживает проблему и сообщает о ней разработчику. Ветка все еще существует в репозитории QA, но на самом деле она ожидает, пока разработчик внесет исправление, прежде чем тестирование можно будет перезапустить. Поэтому нам нужен какой-то способ сообщить об этом другим тестировщикам, которые могут искать что-то для начала тестирования. - person DaveJohnston; 19.01.2011