Структуризация проектов и решений для управления исходным кодом в Team Foundation

Ветвление папок

Чтобы изолировать разработку при помощи ветвления, создайте дополнительные папки в папке Main или разместите в ней дополнительные файлы решений (.sln) Visual Studio, которые позволят разработчикам работать с различными группами проектов. Ветви в подпапках исходного кода Main могут использоваться для текущего сопровождения выпусков продукта или параллельных потоков разработки.

В приведенном ниже примере в дополнение к корневой папке Main используется папка Development (ответвление Main ), предназначенная для изоляции по функциям или по группам. Папка Releases предназначена для хранения ветвей выпусков (еще одно ответвление Main ) и обеспечивает изоляцию выпущенных сборок, требующих текущего сопровождения, и текущего выпуска.

{
  $MyTeamProject1
    /Development
      /FeatureBranch1 
          /Source
              /MyApp 
                /FeatureBranch2  
                  /Source
                     /MyApp
   /Main
     /Source 
   /Releases
      /Release1    Сопровождение 
        /Source
          /MyApp 
             /Release2    Сопровождение 
                /Source
                 /MyApp
                   /Release3    Изоляция текущего выпуска   
                         /Source
                           /MyApp
}

Примечание Не увлекайтесь ветвлением. Если потребуется, вы можете пометить выпуск и выполнить ветвление позже.

Подробнее о группировании проектов и структуре решений - в лекции 3. Подробнее о сценариях ветвления и структурах связанных папок - в лекции 5.

Знакомство с рабочими областями

Рабочая область ( workspace ) TFS является клиентской копией файлов и папок из системы управления исходным кодом TFS. По сути, рабочая область отображает папки системы управления исходным кодом в папки локальной системы. Допустим, вы изменяете файлы в рабочей области локального компьютера. Эти незавершенные ( pending ) изменения изолируются в рабочей области, пока вы не вернете их на сервер как целое. Совокупность изменений, возвращаемых на сервер пакетом, называется набором изменений ( changeset ).

Одна рабочая область может содержать ссылки на несколько проектов. С помощью рабочей области вы также можете изолировать файлы или версии для персонального пользования. Рабочие области назначаются компьютеру или учетной записи пользователя. Поэтому на каждом компьютере, которым вы пользуетесь, рабочие области могут определяться по-своему. Кроме того, как пользователь вы можете иметь несколько рабочих областей на одном компьютере.

Примечание Все физические положения в локальной файловой системе вы можете отобразить посредством только одной рабочей области. Однако вы вольны при помощи разных рабочих областей сопоставить любой папке сервера разные локальные папки.

Создание сопоставления рабочей области

Сопоставления являются рекурсивными, поэтому когда вы создаете новое сопоставление рабочей области и выполняете операцию Get Latest Version в корневой папке этой рабочей области, автоматически создается вся структура локальных папок, идентичная структуре на сервере.

Создавая сопоставления новых рабочих областей, имейте в виду следующее:

• Прежде чем в первый раз добавить решение в систему управления исходным кодом, убедитесь в том, что в локальной системе используется правильная структура папок.
• Впервые создавая сопоставление рабочей области для проекта и выполняя операцию Get Latest, убедитесь, что корневая папка проекта сопоставлена соответствующей локальной папке, например, C:\DevProjects\ TeamProject1.

Где хранятся сопоставления рабочих областей?

Информация о рабочих областях хранится как на клиентском компьютере, так и на сервере. На клиентском компьютере она содержится в файле VersionControl.config, расположенном в папке \Documents and Settings\[user]\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache.

В файле VersionControl.config имя рабочей области сопоставлено с папкой на локальном компьютере. Конкретные папки системы управления исходным кодом с локальными папками в нем не сопоставляются. Эта информация содержится на сервере в нескольких таблицах (в частности, tbl Workspace и tbl_workingfolder ) в БД TfsVersionControl.

Сокрытие

Сокрытие ( cloaking ) используется для повышения производительности, а также для предотвращения извлечения части дерева исходного кода. Ниже описаны типичные ситуации, в которых используется сокрытие:

• Вы выполняете сборку проекта локально, и некая папка для сборки не требуется (например, папка с документацией).
• Вы работаете в команде крупного проекта и хотите извлекать только часть проекта.

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

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

Какие файлы включать в систему управления версиями?

Ниже приводится список основных типов файлов, которые следует добавлять в систему управления исходным кодом. Именно они добавляются, когда вы щелкаете Add Solution to Source Control.

• Файлы решений (*.sln) Список составляющих проектов, информация о зависимостях, а также о конфигурации сборки и поставщике системы управления исходным кодом.
• Файлы проекта (*.csproj или *.vbproj) Параметры сборки, ссылки на файлы сборки (по имени или пути) и опись файлов.
• Метаданные проекта Visual Studio Source Control (*.vspscc) n Связывания проектов, списки исключений, имена поставщиков и другие метаданные системы управления исходным кодом.

• Файлы конфигурации приложения (*.config) XML -файлы конфигурации с индивидуальными настройками проекта и приложения для управления поведением приложения во время его выполнения. Для веб-приложений используются файлы Web.config, для остальных приложений - файлы App.config.

  Примечание Во время выполнения система сборки Visual Studio копирует файл App.config в папку Bin проекта и переименовывает его в <имя_приложения>.exe.config. Для всех приложений, кроме веб-приложений, файл конфигурации в новый проект автоматически не добавляется. Если он вам нужен, добавьте его вручную. Убедитесь, что присвоили ему имя App.config, и поместите его в папку проекта.
• Файлы исходного кода (*.aspx, *.asmx, *.cs, *.vb, …) Исходный код для разных приложений и языков.
• Двоичные файлы (*.dll) Если ваш проект зависит от двоичных файлов, например, от DLL -библиотек сторонних производителей, их также следует добавить в проект. Подробнее об управлении зависимостями - в лекции 6.

Какие файлы не включать в систему управления исходным кодом?

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

• Файлы пользовательских параметров решения (*.suo) Персональные настройки среды IDE Visual Studio для конкретного пользователя.
• Файлы пользовательских параметров проекта (*.csproj.user или *.vbproj.user) Персональные параметры проекта, относящиеся к разработке, а также при необходимости путь к файлам сборки, на которые есть ссылка в проекте.
• Файлы WebInfo (*.csproj.webinfo или *.vbproj.webinfo) Расположение виртуального корневой папки проекта. Эти файлы не добавляются в систему управления исходным кодом, чтобы отдельные разработчики могли определять для рабочей копии проекта различные виртуальные корневые папки. Впрочем, несмотря на наличие этой возможности, при разработке веб-приложений всем членам команды рекомендуется использовать согласованное расположение виртуальной корневой папки.
• Результаты сборки Сборки DLL, межоперационные сборки DLL и исполняемые файлы ( EXE ). Помните, что сборки, например, двоичные файлы сторонних производителей, которые не участвуют в процессе сборки, тем не менее, следует помещать в систему управления версиями.

Резюме

Для эффективной командной разработки необходимо структурировать проекты в системе управления исходным кодом TFS. Для объединения проектов Visual Studio используйте корневую папку Main, создавая в ней вложенные папки для хранения различных данных проекта - исходного кода, тестов, документации и типов командной сборки.

Используйте SharePoint для хранения внутренней документации, например, сценариев использования и проектной документации. Для документации продукта, которую вы планируете поставлять клиентам (руководств по установке и развертыванию, руководства пользователя, файлов справки), используйте систему управления исходным кодом TFS.

Синхронизируйте структуру папок на сервере и клиенте, чтобы сократить организационную путаницу. Для оптимизации работы в крупных проектах создавайте сопоставления рабочих областей для корневой папки, чтобы обеспечить извлечение только нужных в работе файлов.

Дополнительные ресурсы

• Перечисленные ниже разделы из части "Практикум" В них подробно описаны процедуры, обсуждаемые в этой лекции.
  • "Как создать дерево кода в Team Foundation Server ".
  • "Как структурировать приложения ASP.NET в Visual Studio Team Foundation Server ".
  • "Как структурировать приложения Windows в Visual Studio Team Foundation Server ".
  • "Как структурировать папки управления исходным кодом в Visual Studio Team Foundation Server ".
• Дополнительную информацию о системе управления исходным кодом Team Foundation вы найдете в статье "Using Source Code Control in Team Foundation" по адресу http://msdn2.microsoft.com/en-us/library/ms364074 (VS.80).aspx.
• Дополнительную информацию о создании рабочей области вы найдете в статье "How to: Create a Workspace" по адресу http://msdn2.microsoft.com/ en-us/library/ms181384(VS.80).aspx.