Структура TFS-несколько проектов или один проект?

наш небольшой магазин разработки хочет перенести наши проекты с VSS на TFS, и мы оцениваем TFS против других (еще не нажали на курок). Природа нашего магазина программного обеспечения такова, что у нас есть 100+ проектов в VSS, начиная от небольших проектов одного человека-шоу до массовых корпоративных приложений.

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

с этим типом установки мы обеспокоены тем, что мы потеряем много функций, которые предоставляет TFS (отслеживание ошибок, Scrum burndowns, отчетность, хранение документов и т. д.) потому что все проекты будут находиться в одном пространстве портала / проекта, и будет трудно отделить отдельные билеты/элементы проекта.

У кого-нибудь есть опыт в этом? Каким было ваше решение? Ты придерживался TFS?

8
team-project tfs version-control

6 ответов

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

  1. вам понадобится [по крайней мере] 1 командный проект на шаблон процесса. То есть, если две команды хотят принять / настроить разные процессы, их нужно будет разделить.

  2. Как только условие #1 удовлетворено, вам вероятно не нужно как много отдельных командных проектов, как вы думаете. 90% функций и настроек TFS имеют иерархическую природу, что позволяет вам охватывать их так широко или узко, как требует каждый из ваших проектов.

для получения полной информации см.:

6

подход, который я принял, состоял в том, чтобы иметь проект TFS для каждой логической группировки сборок-поэтому у нас есть проект framework, который содержит сборки, общие для всех наших приложений, затем у нас есть отдельный проект для нашей системы котировок, другой для системы затрат и так далее. В то время как сопоставления рабочих областей становятся немного "интересными", они позволяют использовать разные методологии проектирования для разных проектов и в разных временных масштабах, поэтому одна команда может быть на полпути через спринт (Большинство проектов используют Scrum для командной системы), в то же время как другой только начинает...

2

Это правда, что для получения всех преимуществ TFS лучше всего использовать отдельные проекты, но эти преимущества следует взвесить с административными накладными расходами, связанными с управлением многими проектами. Много лет назад я использовал Visual Source Safe...После того, как я покинул Microsoft, я переключился на Subversion. После возвращения в Microsoft я использую TFS, и до сих пор я очень доволен этим.

руководство процессом, отчеты, интегрированное отслеживание ошибок и тесная интеграция IDE служите моим потребностям совершенно. Плюс, в TFS SDK позволяет за несколько интересных сценариев extensibiilty.

2

Я использовал несколько поставщиков SCC, и мы остановились на TFS для всех функций, которые у него есть, что другие нет. Корреляция ошибок, CI и автоматическое тестирование, безусловно, возглавили список преимуществ.

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

1

Я не уверен, что это было исправлено в 2008 году, но в 2005 году, когда вы создали проект, который был подпапкой корневого проекта, MSBuild вытащит все исходное дерево корневого проекта - даже файлы, которые не являются частью вашей подпапки.

в зависимости от источника управление это может значительно увеличить время сборки.

0

Я понимаю, что эта статья старая, но TFS 2010 теперь поддерживает замечательную функцию Call Team Project Collections, которая является просто еще одним уровнем косвенности или группировки поверх проектов.

Это упрощает создание командных проектов без засорения пространства имен и способствует лучшей организации!

Great Link подробнее о Сборники

http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx

Я не пользователь sharepoint, но я слышу его очень похожую концепцию на коллекции Sharepoint:)

0