Лучшие практики для иерархии TFS - PullRequest
0 голосов
/ 29 апреля 2019

В моей компании есть несколько подразделений, и многие проекты выполняются в разных версиях Visual Studio, поэтому я подумал о создании структуры ниже tfs только для одной коллекции проектов:

My_Project_Collection
   |
   |___ Division_1
   |       |
   |       |__ VS2010
   |       |__ VS2012
   |       |__ VS2013
   |             |
   |             |__ Team_Project_1
   |             |      |__ Main
   |             |      |__ Dev
   |             |      |__ Release
   |             |
   |             |__ Team_Project_2
   |                    |__ Main
   |                    |__ Dev
   |                    |__ Release
   |
   |___ Division_2
   |
   |___ Division_N

У меня вопрос: стоит ли классифицировать командные проекты по версии visual studio (VS2010, VS2012, VS2013 и т. Д.) Или нет необходимости?

Division_2, ... Division_N имеют ту же структуру, что и Division_1

1 Ответ

0 голосов
/ 29 апреля 2019

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

* 1003 Е.Г. *

My_Project_Collection
   |
   |___ Division_1
   |       |
   |       |
   |       |__ Team_Project_1 - AP VS2013
   |       |      |__ Main
   |       |      |__ Dev
   |       |      |__ Release
   |       |
   |       |__ Team_Project_2 - AP VS2010
   |              |__ Main
   |              |__ Dev
   |              |__ Release
   |
   |___ Division_2
   |
   |___ Division_N

См. В этом SO аналогичный вопрос: Должен ли я создать один или несколько командных проектов VSTS? что вы уже делаете, имея одну коллекцию проектов из того, что я могу собрать.

А также проверьте этот блог, на который есть ссылка в этом ответе: Почему вы должны использовать один (гигантский) TFS Team Project . Должны применяться те же преимущества / недостатки ... просто подумайте, где вы хотите, чтобы ваши границы и ваша структура отражала это.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...