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

Question

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

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

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

С момента последнего развертывания QA могло произойти несколько сборок ветки Main.Эти сборки связаны с наборами изменений «Объединение», а не с исходными наборами изменений, которые были связаны с Задачами.

Как определить набор задач, которые были решены с помощью данной сборки «Основные», котораяявляется ли сборка ветки, отличной от той, которая связана с рабочими элементами Задачи?

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

---

PS Приходит вопрос " Как определить рабочие элементы, связанные с веткой источника в TFS 2010? "близок к тому же вопросу, но не совсем.

Answer 1

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

Answer 2

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

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