TFS: как представить версию приложения, в которой каждый запрос на изменение, ошибка и т. Д. Будет рассмотрена в

Question

Мы недавно перешли от Gemini к TFS для управления изменениями приложений. Есть один аспект TFS, с которым я не могу разобраться - отсутствие встроенной концепции версии приложения, в которой каждый рабочий элемент будет адресован в.

В Gemini каждый запрос, усовершенствование, ошибка и т. Д. Можно пометить номером версии. Если поле осталось пустым, элемент был «незапланированным», т. Е. На отставании. Каждая версия может быть помечена как выпущенная, так и нет. Затем могут быть созданы отчеты, в которых перечислены проблемы, рассмотренные в каждой выпущенной версии, то есть примечания к выпуску, и проблемы, которые должны быть рассмотрены в будущих версиях, то есть дорожная карта. Я был полностью доволен этим!

Теперь в TFS я не могу найти встроенную концепцию версии. Кажется, есть два способа представления версии:

В качестве родительского элемента в дереве итерации, например.

версия 1.0.0

• Спринт 1
• Спринт 2
• т.д.

версия 1.1.0

• Спринт 3
• Спринт 4
• т.д.

Как родительского элемента в дереве рабочих элементов, например,

версия 1.0.0

• Требование 1
• Требование 2
• т.д.

версия 1.1.0

• Требование 3
• Ошибка 4
• и т.д.

Последний подход выглядит лучше, потому что он позволяет версия должна быть разработана одновременно (например, основной выпуск будет работать одновременно с выпуском исправления ошибок).

Итак, каков рекомендуемый подход к управлению работой по версии?

И наконец, если свойство версии фактически не присутствует в самом рабочем элементе, можно ли создавать отчеты по вопросам, адресованным в каждой версии?

Answer 1

Сейчас я собираюсь использовать итерационный путь, чтобы захватить номер версии. Это не так хорошо управляет разработкой на разных версиях одновременно, но мы пытаемся уйти от этой практики (т. Е. Работать над следующим выпуском, одновременно работая над несколькими исправлениями ошибок в прошлых выпусках) и принимать короткие циклы выпуска , т.е. более линейный путь, так что, возможно, это хорошо.

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

Answer 2

Вы можете использовать поле области.

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

Другая возможность - использовать теги в верхней части элемента отставания продукта.

Btw, я согласен, что TFS не хватает нескольких важных полей (пользовательские поля)

Answer 3

1. Метки (TFS 2013+) - это самый простой способ добавить метаданные, такие как build #. (Такой же, как указано выше.)

2. CMMI Process Template>Требование и Bug Типы рабочих элементов есть поле «Integrated In», ссылки на TFS Сборки для прямой связи с требованием построить # [к связанным изменениям кода] [к связанным тестовым случаям [к связанным результатам тестирования]]. Обратите внимание, что вы должны выбрать из сохраненных сборок системы TFS Build (которые не были удалены). Это всплывающее раскрытие справки ограничивает это поле значительно с течением времени или если вы используете другую систему сборки. (Это и построение версий - это совершенно разные обсуждения :-).) Поля шаблонов Build CMMI существуют с TFS2010.

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

p.s .: Извините за поздний ответ. Я отправил этот ответ, если у других по-прежнему есть тот же или похожий вопрос.