Как определить рабочие элементы Исправлено в конкретной сборке TFS при использовании ветвей?

Мы начали использовать следующую структуру ветвления в TFS 2010:

Все изменения до сих пор были выполнены в ветке "Развитие", и все проверки были связаны с рабочим элементом "Задача". Задачи - это все дети, работающие с элементами Bug или Product Backlog Item. Каждая сборка CI запускается для определенного набора изменений, а набор изменений связан с Task, поэтому мы можем вручную определить, какой Bug или PBI был только что построен.

Через некоторое время после создания кода, развернутого в нашей среде интеграции и протестированного разработчиком, он объединяется с главным филиалом. Очевидно, что более одного набора изменений может быть одновременно объединено с Main. Ночная сборка построит этот код, если мы не будем вручную запускать ночь перед этим. QA позже будет развертывать одну из этих "основных" сборников в среде QA.

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

Как определить набор задач, которые были адресованы данной сборкой "Главная", которая представляет собой сборку другой ветки, чем сборка, связанная с рабочими элементами "Задача"?

Как только мы начнем подготовку к выпуску, нам может потребоваться внести изменения в ветку Release, что усложнит ситуацию, так как мы сможем объединиться с Release to Main, а изменения изменений будут связаны с Задания. Затем они будут объединены с развитием, что сделает жизнь еще более интересной!

P.S. Вопрос "Как определить рабочие элементы, связанные с ветвью источника в TFS 2010?, близок к заданию одного и того же вопроса, но не совсем.

Ответ 1

Взгляните на сообщение блога Джейкоба Эна Автоматическое объединение рабочих элементов в TFS 2010. Он написал подключаемый модуль, который можно загрузить из codeplex. Он автоматически свяжет рабочие элементы, связанные с объединенными наборами изменений. Поэтому, когда вы объединяетесь в Main или Release, рабочие элементы будут связаны с наборами изменений в этих ветвях, а рабочие элементы будут включены в отчеты сборки для сборки этих ветвей. Плагин очень прост для развертывания.

Ответ 2

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

У меня может быть несколько примеров кода, чтобы вы начали с обхода дерева истории слияния, если вы хотите связаться со мной по адресу http://www.edsquared.com