Мы используем Visual Studio 2010 и TFS.У нас есть 4 среды, которые мы используем.Они следующие:
- DEV - для команды разработчиков для тестирования интеграции
- QA - для нашей команды QA для выполнения своих тестов
- UAT - для наших пользователейчтобы выполнить их тесты
- PROD - наша производственная среда
Правильно или неправильно, мы используем следующую стратегию ветвления в TFS:
MAIN> DEV> QA>UAT> RELEASE
Решено начать разработку нового проекта, и мы назовем его «Release 1.0»
- Release 1.0
InTFS, наши филиалы выглядят так:
MAIN> DEV 1.0> QA 1.0> UAT 1.0> RELEASE 1.0
Выпуск 1.0 завершен и приступает к работе.На этом этапе мы определяем, что хотим сократить 2 новые ветви (1.1 и 1.2), которые будут выпущены в разное время.Теперь мы хотим начать разработку следующих двух выпусков:
- Выпуск 1.1 (будет выпущен через 30 дней)
- Выпуск 1.2 (будет выпущен через 60 дней)
Новые ветви в TFS выглядят следующим образом:
MAIN> DEV 1.1> QA 1.1> UAT 1.1> RELEASE 1.1
MAIN> DEV 1.2> QA 1.2> UAT 1.2>RELEASE 1.2
Приоритеты дефектов от 1.0 имеют приоритет, и для разных выпусков выделены две команды.
Мы решили, что хотим сократить сборку ветви 1.1 до QA, и хотели бы предоставитьсписок дефектов, которые были устранены в ветке 1.1.Мы не хотим включать дефекты, которые были устранены в ветке 1.2.
Кто-нибудь знает, как мы можем это сделать?У меня есть фрагмент кода, который я написал, который обращается к объектной модели TFS и попытается получить список на основе связанных наборов изменений.Это начинает усложняться, когда вы начинаете говорить о слияниях между выпусками.Что происходит, когда ошибка разрешается в ветке 1.1, объединяется в MAIN, а затем в ветку 1.2.Технически этот дефект был исправлен в ветке 1.1, но теперь QA имеет его как часть их сборки 1.2.
Есть мысли?