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

Question

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

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

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

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

Версия 1.0.0

• Спринт 1
• Спринт 2
• так далее

Версия 1.1.0

• Спринт 3
• Спринт 4
• так далее

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

Версия 1.0.0

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

Версия 1.1.0

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

ps: извините за поздний ответ. Я разместил этот ответ на тот случай, если у других возникнет такой же или похожий вопрос.

Answer 3

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

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

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

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