Организация проекта все еще в значительной степени субъективна, хотя с этим мы все боремся, когда начинаем с Team Foundation Server. Документация ALM полезна, и на самом деле есть более новая версия документации, на которую я бы порекомендовал опираться. Вы можете получить его в CodePlex по адресу Руководство по ветвлению TFS в Visual Studio 2010 . Даже если вы не планируете ветвления, всегда полезно иметь возможность сделать это в том случае, если вам это необходимо.
Используйте более раннее руководство, и в этом более новом, у меня есть структура, которую я использую как образец. Я покажу вам структуру, включающую только ветку «Main», и если вы используете ветвление, вы можете понять, что все, что находится под «Main», будет воспроизводиться по мере необходимости для каждого.
$/Team Project Root
/Main
/Documentation
/Project A
{XML Help support - such as Sandcastle projects}
/Project B
{XML Help support - such as Sandcastle projects}
/References
{3rd party and scripts to install any the GAC, as/if needed}
/Source
/Project A
{Project file, and associated source}
/Project B
{Project file, and associated source}
/Tests
/Project A
{Project file, and associated source}
/Project B
{Project file, and associated source}
{Solution Files}
Это хорошо нам служит и должно служить ориентиром. Вы должны быть готовы признать, что по мере того, как все меняется, и вы все больше и больше используете систему в своей организации, ваши потребности также могут измениться. Позвольте мне кратко остановиться на каждой из папок верхнего уровня в разделе Main:
Документация. Я часто использую конструктор файлов справки Sandcastle и продвигаю проекты документации на свой уровень в иерархии, как это делают источник и тесты.
Ссылки. Я видел, как люди по-разному относятся к аргументам относительно принадлежности сборок внутри Team Foundation Server. Раньше я был против, но обнаружил, что эта структура папок меняется не часто, связанные проекты часто имеют достаточное количество одинаковых ссылок, и новый разработчик должен иметь возможность получить все, что им нужно, одним махом, чтобы запустить проект и работает.
Источник - Довольно понятен. Связанные проекты, каждый вложенный в свою папку. Папки и проекты именуются по полному пространству имен.
Тесты - То же, что и исходная папка, но артефакты предназначены исключительно для тестирования. Обычно «Проект A» в Source имеет соответствующий «Проект A» в тестах с добавлением .Tests как части пространства имен.
Я поместил все решения в ветку, так что это «одна остановка покупки» в нескольких представлениях в приложении. Я считаю, что это избавляет от необходимости всегда работать в одном «мега-решении».
Что касается ветвления, вы добавляете их по мере необходимости, чтобы не перегружать. Руководство, приведенное выше, действительно хорошо справляется с постепенным внедрением ветвления, и я согласен с идеей начать с простой структуры и строить, когда диктуется спрос. Используемая нами структура хорошо работает в производственном проекте, а также является структурой, которую я использую в своих личных проектах.