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

Question

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

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

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

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

Answer 1

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

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

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

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

• http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=Guidance%20for%20Structuring%20Team%20Projects
• http://blogs.msdn.com/richardb/archive/2007/05/01/tfs-team-project-whitepaper.aspx
• http://msdn2.microsoft.com/en-us/library/aa974183(vs.80).aspx

Answer 2

Подход, который я выбрал, состоял в том, чтобы иметь проект TFS для каждой логической группы сборок. Таким образом, у нас есть каркасный проект, который содержит сборки, общие для всех наших приложений, затем у нас есть отдельный проект для нашей системы предложений, другой для системы калькуляции и так далее. Хотя отображения рабочей области становятся немного «интересными», они допускают разные методологии проектирования для разных проектов и в разные сроки - так что одна команда может быть на полпути через спринт (большинство проектов используют Scrum для Team System ), в то время как другой только начинает ...

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Великая Ссылка говорит больше о коллекциях

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

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

Answer 6

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

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