Структурирование проектов и решений в системе контроля версий Team Foundation Server (TFS)

Written on . Posted in Разработка и тестирование

ОГЛАВЛЕНИЕ

Многие стандартные соглашения по организации хранения файлов, используемые Visual Studio при создании новых решений и проектов, не оптимизированы для коллективной разработки и использования с системой контроля версий TFS. Поэтому при создании новых проектов и решений Visual Studio необходимо тщательно прорабатывать локальную и серверную структуры каталогов, а не принимать схему по умолчанию.

Эта статья начинается с объяснения того, как должны быть структурированы решения и проекты на компьютере разработчика (на стороне клиента) и как необходимо структурировать каталоги в системе контроля версий TFS (на стороне сервера). Представлены примеры структур каталогов для различных типов приложений, включая Microsoft Windows® Forms, смарт-клиенты и Веб-приложения. Кроме того, в главе рассматривается использование рабочих пространств для отображения структур каталогов клиента и сервера.


Структура на стороне сервера

Большинство разрабатываемых группой проектов включают одно или более решений Visual Studio, каждое из которых, в свою очередь, включает один или более проектов Visual Studio. При организации изолированных ветвей разработки проекты Visual Studio группируются в корневую папку Main (как на стороне клиента, так и на стороне сервера). Ниже представлен пример структуры каталогов в системе контроля версий TFS: 

$MyTeamProject1
    /Main                                   // Может содержать файлы решений (.sln) 
        /Source 
            /MyApp1                         // Содержит файл MyApp1.sln 
                /Source                     // Папка-контейнер всего исходного кода 
                    /ClassLibrary1          // Содержит ClassLibrary1.csproj 
                    /MyApp1Web              // Содержит Default.aspx 
                /UnitTests                  // Папка-контейнер всех модульных тестов 
                    /ClassLibrary1Tests     // Содержит проект тестирования и исходный код тестов 
                    /MyApp1WebTests         // Содержит проект тестрования и исходный код тестов 
            /SharedBinaries                 // Совместно используемые двоичные файлы, например, библиотеки 
            /SharedSource                   // Совместно используемый исходный код 
    /Docs                                   // Содержит документацию продукта 
    /Tests                                  // Контейнер тестов 
        /FunctionalTests 
        /PerformanceTests 
        /SecurityTests
    /TeamBuildTypes                         // Создается автоматически Team Build 
        /BuildType1 
        /BuildType2

Main – это папка-контейнер исходных файлов и других артефактов, таких как результат сборки, проектная документация и сценарии тестирования. Папка приложения (как MyApp1 в предыдущем примере) содержит файл решения Visual Studio (.sln), используемый для группировки множества взаимосвязанных проектов Visual Studio. Каждый файл проекта (.vcproj или .vbproj) размещается в специальной папке проекта, находящейся внутри папки /Main/Source/MyApp1/Source. Модульные тесты, сопровождающие каждый проект, располагаются в папке UnitTests (Модульные тесты). В папку Main можно поместить и другие файлы решений Visual Studio (.sln), что позволит работать с разными вариантами группировки проектов.

Папки Docs и Test используются для размещения дополнительных артефактов, включая документацию по продукту и автоматизированные тесты.

Папка TeamBuildTypes (Типы сценариев сборки) создается автоматически при настройке первого типа сценария сборки. Чтобы вручную зарегистрировать тип сценария сборки, можно создать эту папку самостоятельно, добавить в нее свои файлы Team Build, и TFS распознает эту папку автоматически.


 

Хранение модульных тестов

Модульные тесты можно сохранять в папке UnitTests и располагать ее на одном уровне с папкой Source, как показано ниже:

… 
/MyApp1                         // Содержит файл MyApp1.sln 
    /Source                     // Папка-контейнер всего исходного кода 
        /ClassLibrary1          // Содержит ClassLibrary1.csproj 
        /MyApp1Web              // Содержит Default.aspx 
    /UnitTests                   // Папка-контейнер модульных тестов 
        /ClassLibrary1Tests     // Содержит проект тестирования и исходный код тестов
        /MyApp1WebTests         // Содержит проект тестирования и исходный код тестов

При таком сценарии модульные тесты выносятся отдельно от всего исходного кода. Однако происходит это за счет совместимости на уровне проектов. Вот альтернативная структура: 

/MyApp1 
    /Source 
        /ClassLibrary1 
        /ClassLibrary1Tests 
        /MyApp1Web 
        /MyApp1WebTests

За и против каждого из подходов:

UnitTests на одном уровне с папкой Source

За: Все модульные тесты находятся в одном месте.
За: Поставляемый код располагается отдельно от кода, который поставляться не будет.
За: Процесс сборки может без труда выполнить все модульные тесты во всех проектах.
Против: Разработчикам сложнее выполнять модульное тестирование только для своего проекта.
Против: Модульные тесты не включаются в ответвления папки Source.

UnitTests в каждом проекте

За: Разработчики могут без труда выполнять модульные тесты для отдельного проекта.
За: При ветвлении, папки с модульными тестами включаются в структуру папок создаваемой ветви. Таким образом, модульные тесты могут сохранять тесную связь с исходным кодом в каждой ветви.
Против: Происходит смешение поставляемого кода и кода тестов в папке исходного кода.
Против: Обычно сложнее выполнить модульное тестирование сразу по всем проектам во время сборки.


Хранение документации

Папка Documentation (Документация) предназначена для хранения документации проекта. Чтобы определиться с тем, где хранить те или иные документы (в системе контроля версий TFS или на сайте портала проекта Microsoft Windows SharePoint), учитываем следующее:

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

Большинство документов являются двоичными файлами, поэтому во избежание ручного слияния версий исходного кода рекомендуется использовать блокировку взаимоисключающего доступа. Тогда при попытке открыть используемый файл будет поступать уведомление, что поможет исключить ручное слияние. Следует быть осторожными при использовании SharePoint, поскольку в этом случае требуется жесткий контроль версий документа. В SharePoint проще перезаписать изменения по сравнению с системой контроля версий TFS. По умолчанию SharePoint при закачивании файлов включает опцию «overwrite existing file» (перезаписать существующий файл).


Структура на стороне клиента

Локальная структура каталогов на рабочих станциях разработчиков должна быть идентична структуре каталогов на стороне сервера. Артефакты исходного кода на рабочих станциях должны быть хорошо организованы: исходные файлы всех проектов группы должны размещаться в одной корневой папке, например, C:\DevProjects. Для каждого проекта группы создается отдельная подпапка, как показано в данном примере: 

C:\DevProjects         // Корневая папка-контейнер для всех проектов группы 
    \MyTeamProject1         // Папка-контейнер для TeamProject1 
    \MyTeamProject2    // Папка-контейнер для TeamProject2

В каждой папке проекта группы воспроизводится копия структуры каталога приложения, используемой на сервере системы контроля версий, как показано в следующем примере: 

\MyTeamProject1                               // Папка-контейнер для TeamProject1 
    \Main                                     // Содержит файлы .sln, объединяющие проекты
        \Source
            \MyApp 1                          // Содержит MyApp1.sln 
                \Source 
                    \ClassLibrary1            // Содержит ClassLibrary1.csproj 
                    \MyApp1Web                // Содержит Default.aspx 
                \UnitTests                    // Содержит проекты и исходный код модульных тестов 
                    \ClassLibrary1Tests 
                    \MyWinApp1Tests 
            \SharedBinaries                   // Совместно используемые двоичные файлы, например, библиотеки 
            \SharedSource                     // Совместно используемый исходный код 
        \Docs                                 // Содержит документацию продукта 
        \Tests                                // Контейнер тестов 
            \FunctionalTests 
            \PerformanceTests 
            \SecurityTests

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


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

Изолированность разработки обеспечивается ветвлением. Для этого на одном уровне с папкой Main создаются дополнительные папки. Также, чтобы обеспечить разработчикам возможность работать с различными вариантами группировки проектов, в папке Main можно разместить дополнительные файлы решений Visual Studio (.sln). Ветви, созданные от папок исходного кода 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 «Выбор стратегии ветвления и слияния».


Что такое рабочее пространство TFS

Рабочее пространство TFS – это копия файлов и папок системы контроля версий TFS на стороне клиента. Рабочее пространство проецирует папки системы контроля версий в каталоги локальной файловой системы. Изменения, вносимые в файлы в рабочем пространстве на локальном компьютере, называют локальными или ожидающими регистрации изменениями (pending changes). Они остаются изолированными в рамках рабочего пространства до тех пор, пока не будут зарегистрированы на сервере как единое целое. Совокупный набор изменений, регистрируемый пакетом, называют пакетом изменений (changeset).

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

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


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

Отображения рекурсивны, поэтому при создании нового отображения рабочего пространства и выполнении операции Get Latest Version (Получить последнюю версию) в корне этого рабочего пространства, вся локальная структура каталогов создается автоматически. Вновь созданная локальная структура каталогов полностью соответствует структуре каталогов сервера.

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

  1. Лицо, ответственное за проект, прежде чем впервые добавить решение в систему контроля версий, должно убедиться в том, что на локальном уровне используется верная структура каталогов.
  2. При отображении рабочего пространства проекта группы впервые и осуществлении операции 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.


Сокрытие

Если требуется предотвратить возможность извлечения какой-либо части дерева каталогов системы контроля версий для оптимизации производительности, можно использовать сокрытие. Вот типичные сценарии сокрытия:

  1. Требуется произвести сборку проекта локально и имеется папка, которая не должна участвовать в сборке, например, папка документации.
  2. Вы являетесь частью большой группы, работающей над проектом, и хотите получить только часть проекта.
Для любого из приведенных сценариев можно скрыть папки, чтобы лишить клиента TFS возможности доступа к ним. Сокрытие папок на клиенте осуществляется путем редактирования рабочего пространства и изменения статуса рабочей папки с «активная» на «скрытая». При сокрытии необходимо учитывать следующие рекомендации:
  1. Не следует скрывать отдельные файлы. Позднее это может привести к проблемам обслуживания в проекте.
  2. В большом проекте лучше отображать корневую папку и скрывать подпапки, а не создавать несколько рабочих пространств.


Для каких файлов необходимо выполнять контроль версий?

В следующем списке перечислены основные типы файлов, которые должны быть включены в систему контроля версий. Эти типы файлов добавляются по выбору пункта меню Add Solution to Source Control (Добавить решение в систему контроля версий).

  1. Файлы решений (*.sln). В файлах решений хранится список входящих в них проектов, информация о зависимостях, детали конфигурации сборки и информация о провайдере системы контроля версий.
  2. Файлы проектов (*.csproj или *.vbproj). Файлы проектов включают настройки процесса сборки, используемые сборки (имя и путь) и перечисление входящих в проект файлов.
  3. Метаданные проекта системы контроля версий Visual Studio (*.vspscc). В этих файлах хранятся связи проекта, списки файлов, не находящихся под версионным контролем, имена провайдеров системы контроля версий и другие метаданные системы контроля версий.
  4. Конфигурационные файлы приложения (*.config). Конфигурационные файлы XML содержат характерные детали проекта и приложения, которые используются для управления поведением приложения во время выполнения. Веб-приложения используют файлы Web.config. Не Веб-приложения используют файлы App.config.
    Примечание:     Во время выполнения система сборки Visual Studio копирует App.config в папку Bin проекта и переименовывает его в <ИмяВашегоПриложения>.exe.config. Для не веб-приложений не происходит автоматического добавления конфигурационных файлов в новый проект. Если такой файл необходим, следует добавить его вручную. Он должен называться App.config и располагаться в папке проекта.
  5. Исходные файлы (*.aspx, *.asmx, *.cs, *.vb, …). Это файлы исходного кода. Какие именно это файлы, зависит от типа приложения и используемого языка программирования.
  6. Используемые двоичные файлы (*.dll). Если проект использует двоичные файлы, такие как динамически подключаемые библиотеки (dynamic-link libraries, DLLs) сторонних производителей, они также должны быть добавлены в проект в системе контроля версий. Более подробно об управлении зависимостями рассказывается в Главе 6 «Управление зависимостями системы контроля версий в Visual Studio Team System».


Для каких файлов не требуется контроль версий?

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

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

Заключение

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

SharePoint используется для хранения внутренних документов группы, таких как варианты использования и проектная документация. В системе контроля версий TFS следует размещать документацию продукта, которую планируется поставлять заказчикам. Сюда могут входить руководства по установке и развертыванию, руководства по эксплуатации и файлы Справки.

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

форум программирование