Области TFS, оптимальное определение и конфигурация

Question

После недавнего перехода на TFS 2010 мне стало интересно, какое самое лучшее или наиболее распространенное определение или конфигурация для Района?

Единственная полезная статья, которую я могу найти в Интернете, это эта , и я бы предположил, что она верна. Однако это заставило меня задуматься о том, действительно ли какое-либо из следующего действительно является более широко распространенным.

• Области по бизнес-функциям
• Области по технологии
• Области по системному слою
• Районы по физическому или географическому положению

Answer 1

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

Наша первоначальная структура TeamProject фактически игнорировала области для нашего флагманского продукта, который мы создаем в Team Collection.Это привело к кошмару отчетности, поскольку он нам нужен на уровне платформы (TeamCollection), а не в отдельной его части (Team Project).Когда мы поняли проблему, мы пошли на поиск и нашли эту статью, которая заставила нас изменить курс: теперь мы используем области TFS в рамках одного командного проекта и нашли то, что лучше всего подходит для нашей ситуации.
В нашей области вселенной = отдельная линия релиза на платформе.

Answer 2

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

Я думаю, что все, что вам подходитпроцесс разработки и / или повышение производительности - это нормально.

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

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