Организация исходного кода в TFS 2010

Ответ 1

Лучшей практикой для этого является наличие всего, что вам нужно для создания решения в папке Main/Trunk. Мы используем следующий формат:

 "Project 1"
   "DEV" (Folder)
      "Feature 1" (Branch)
      "Main" (Root branch)
   "Release" (Folder)
      "Release 1" (Branch)
   "RTM" (Folder)
      "Release 1.0" (Branch)
      "Release 1.1" (Branch)

Это держит все ваши ветки на одном уровне, поэтому у вас нет никаких сомнений относительно того, какая ветка и какая папка.

Это ваша структура Project проекта, но как насчет фактической структуры папок под каждым из ветвей:

Main (Root branch)
  "Builds" (Folder that contains all of the MSBuild and Workflows for building)
  "Documents" (Folder that contains version specific documents)
  "Deployment" (Folder that contains config required for deployment | We use TFS Deployer from Codeplex)
  "Setup" (Folder contains all of the setup resources)
  "[Company].[Namespace].*" (Folders that contains a project)
  "Tools" ( Folder for all your nuts and bolts)
     "Toolname" (Folder for a specific tool or reference library)

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

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

Ссылки: TFS Deployer

Ответ 2

У меня есть два ответа: что мы делаем и что предлагаю для вас.

Для нас у нас есть набор веб-приложений, у которых есть МНОГИЕ общие компоненты. Таким образом, хотя это около 50 различных сборок (VS Projects) и 5-10 решений (в зависимости от того, как вы на это смотрите), есть очень существенное совпадение во всех из них, что означает, что мы хотим использовать TFS per-dev, чем разветвление и объединение этих перекрывающихся ресурсов. Таким образом, мы фактически сохраняем все это в одном проекте TFS. Вот как у нас есть наша настройка (имена изменены, чтобы иметь смысл для вас):

"Official Projects" (Collection)
    "Production Applications" (Project)
    "Technology Proof of Concepts" (Project)
    "Reference Projects" (Project) - this is a simple solution/projects using our architecture to make our architecture easier to understand as people join our team. Other reference apps will go here in the future.
    "TFS Configuration" (Project)
"Playground" (Collection)
    "John Doe" (Project)
    "Jane Doe" (Project)
    "Security Team" (Project)
    "Production Test" (Project)

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

Однако, в вашем сценарии, если я правильно читаю строки, я бы предложил что-то другое. Мои предположения:

• Каждый проект, помимо наличия некоторых общих сборок (я думаю, что протоколирование, безопасность и другие сборки сборок, которые являются общими для всей компании), являются несвязанными проектами.
• Общие/общие сборки не изменяются регулярно, поэтому вы можете использовать ссылки на DLL, а не ссылки на проекты, где вы всегда используете самую последнюю версию кода в минуту/день.
• (предположение, основанное на TFS, поскольку я все еще участвую в нем). Вы можете связываться с проектами из одной коллекции, но вы не можете входить в коллекцию.
• Помимо вышеупомянутых общих сборок, ни один другой код не используется в разных командах.

Таким образом, с этими предположениями я бы пошел примерно так:

"Common Resources" (Collection)
    "Source" (Project) - everything goes here such as logging assemblies, security assemblies, etc.
    "Version 1" (Project) - Branch as you "rev" your common assemblies so people have access to older versions.
    "Version 2" (Project)
    "Version 3" (Project"
    etc.
"Team 1" (Collection)
    "Project 1"
    "Project 2"
    "Project 3"
    "Project 4"
    "Project 5"
"Team 2" (Collection)
    "Project 1"
    "Project 2"
    "Project 3"
"Team 3" (Collection)
    "Project 1"
    "Project 2"
etc.

Выполняя это, вы ссылаетесь на общие сборки через ссылки DLL. Вы, как команда или разработчик по конкретному проекту, решаете, когда начнете использовать более новую версию общей сборки. Для этого вы просто получите последнюю информацию о ветке этой версии, а затем добавьте ссылку на нее. Если мое предположение № 3 неверно, то, надеюсь, вы можете сделать что-то лучше этого. В противном случае каждый проект имеет свое собственное пространство (которое может содержать не более одного VS Solution/Project, что является хорошей идеей), и ваша команда имеет свою собственную коллекцию, чтобы оставаться отдельно от других команд.

Только мои $0,02 стоит...

Ответ 3

Мы применили простой подход к сторонним компонентам и создали для них отдельный проект. Затем, когда другой проект должен ссылаться на сборку или DLL, мы вставляем папку, в которой находится сборка, в папку "ThirdParty" в целевом проекте.

Это также дает нам механизм постепенного развертывания обновлений сторонних сборок с использованием прямого слияния из базовой папки.

Ответ 4

Используйте Workspaces, они не только работают в коллекциях Team, но и будут работать с большинством методов управления версиями.