TFS Рабочий элемент <-> Рекомендации по организации сборки

Question

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

Для каждой так называемой функции, мы создаем следующее:

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

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

Вопрос тогда в том, что является лучшей практикой по связыванию рабочих элементов с сборкой?

В нашем случае эти ветви функций должны быть одноразовыми: мы хотели бы иметь возможность удалить эти сборки/ветви/группы позже, когда эта функция будет завершена, но все же сможет отслеживать их на протяжении всего жизненного цикла продукта ,

Если я свяжу рабочие элементы с этими временными сборками, я потеряю возможность отслеживания позже, когда прекратится реализация функции. В то же время я только что узнал, что gated checkins always associate work items, regardless of what is configured in the build definition.

Было бы возможно отключить интеграцию рабочих элементов с ветвями функций (в этом случае также преобразовать их из стробированной в непрерывную интеграцию) и включить ее в основной сборке, чтобы эти функции можно было отслеживать в основной линейке продуктов ? Или, возможно, это должно быть включено только для определения версии сборки, чтобы мы могли узнать, что было интегрировано в определенный релиз? Для тех из вас, кто придерживается концепции спринта/функции, как вы справляетесь с этой ситуацией? У вас также есть сборка для каждой ветки?

Update:

Я только что нашел что-то подобное (но не точно, как то, что я хотел) в this question. Ответ там привел меня к a plugin that automatically associates work items on merge checkins. Это должно обеспечить отличную прослеживаемость по своему усмотрению, поэтому я думаю, что я сделаю это.

Хотелось бы услышать, что вы думаете о конструкциях в этом сценарии.

Answer 1

Вы приближаетесь к этой неправильной ИМО. Вы не должны беспокоиться об ассоциировании Builds и WI, а скорее об ассоциировании с наборами и WI. Когда ваши разработчики регистрируют изменения в ветви функции, вы должны убедиться, что они связывают их с соответствующими WI (-ами). Вы можете даже принудительно выполнить это с помощью политики регистрации.

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