Как мне настроить командный проект TFS на основе моих реальных реалий?

Question

У нас есть проект, который будет развиваться в несколько этапов в течение следующих 12-18 месяцев.Это очень гибкий проект в среде водопада, это важно.

Сначала я задумался о создании одного командного проекта под названием «Project X».В Project X может быть несколько папок с решениями, но основная разработка будет в папке с именем Main.Разветвление будет выполнено соответствующим образом.

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

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

Имеет ли этот подход смысл?Есть идеи, чтобы улучшить это?Я еще не создал командный проект.

Answer 1

Я просто прокомментирую перечисленные вами преимущества, чтобы помочь вам понять, почему этот подход не идеален.

Преимущества, которые я вижу в этом подходе: а) весь код проектахранится в едином командном проекте и

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

Подумайте, есть ли у вас требование, которое должно работать как с инструментом, так и с основным приложением.В вашем сценарии не было бы возможности отследить историю работы, связанную с одним требованием, потому что вы используете два командных проекта.Есть еще много причин: вам нужно управлять разрешениями в двух местах, иметь два набора сопоставлений и т. Д. И т. Д.

Я настоятельно рекомендую вам использовать один командный проект.Вы и вся ваша команда поблагодарите меня позже.

b) все рабочие элементы, ошибки, элементы списка желаний доступны из всех других проектов

Еслиу вас есть два командных проекта, вы не можете получить доступ к WI и т. д. во всех проектах.Фактически, у вас будет полная противоположность - вам придется создавать WI в обоих проектах, если работа пересекается между ними.

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

Вот хорошее место для начала чтения перед настройкой проекта: Руководство по ветвлению на сервере Microsoft Team Foundation Server .

Answer 2

То, что вы описываете, не является командным проектом. Вы просто описываете структуру некоторых папок контроля версий в TFS.

Командный проект - это намного больше, чем просто контроль версий. От T (Глоссарий Visual Studio ALM) :

командный проект

именованная коллекция рабочих элементов, код, тесты, рабочие продукты, метрики, и так далее, используется определенной командой с Visual Studio Team Foundation для отслеживать общий набор связанных работ.