Мы настраиваем TFS 2010, и у нас есть около 15 различных приложений, которые мы хотели бы перенести на TFS. Мы уже решили, что сделаем 1 сборник. У меня возникает вопрос: должны ли мы создавать несколько командных проектов для каждого из наших приложений или мы должны объединить все наши приложения в один командный проект? С какими преимуществами / недостатками мы столкнемся с этими сценариями для рабочих элементов, сборок и т. Д.?
Когда мне создать новый командный проект в TFS 2010?
Ответы (2)
Моя планка того, что должно быть в командном проекте, заключается в том, имеют ли приложения и / или люди, работающие над приложениями, общие ресурсы, такие как рабочие элементы.
В предстоящем TFS11 есть понятие невыполненных работ (если вы еще не видели его, я рекомендую перейти к \ BUILD \ records). Если ваши приложения совместно используют спринты или невыполненные журналы, я бы создал один командный проект (или групповой проект для каждого пула приложений, которые разделяют их).
Если приложения разрабатываются отдельно и вы хотите использовать разные процессы, используйте несколько командных проектов.
Недавно я увидел хороший пост одного из рейнджеров TFS ALM, в котором рассматриваются все основные недостатки разделения на несколько командных проектов.
Однако, как указывает Эвальд, новая поддержка Sprint, Backlog и Team в TFS11 на самом деле является достаточно вескими причинами для разделения ваших проектов.