Управление зависимостями в системе управления исходным кодом Visual Studio Team System

Обзор

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

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

Сценарии и решения

При управлении зависимостями, как правило, реализуются следующие сценарии:

1. Вы хотите установить ссылку на сборку, сгенерированную другим проектом в том же решении.
2. Вы хотите установить ссылку на сборку, сгенерированную проектом в другом решении.
3. Вы хотите установить ссылку на файл сборки, содержащийся в другом командном проекте.
4. Вы хотите установить ссылку на файл сборки стороннего производителя.

Ссылка на файл сборки другого проекта в том же решении

Чтобы создать ссылку на другую сборку того же решения Visual Studio, воспользуйтесь ссылкой на проект Visual Studio. С ее помощью вы дадите Visual Studio указание автоматически выполнять некоторые действия, например, синхронизировать конфигурации сборки ( Debug/Release ), отслеживать версии, а также при необходимости выполнять сборку компонентов.

Ссылка на файл сборки проекта в другом решении

Чтобы создать ссылку на сборку, сгенерированную проектом из другого решения Visual Studio, вы можете воспользоваться двумя способами:

• Используйте файловые ссылки для указания на двоичный файл сборки.
• Добавьте в решение проект Visual Studio (файлы проекта и исходного кода), а затем используйте ссылку на проект.

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

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

Ссылка на файл сборки из другого командного проекта

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

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

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

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

Ссылка на файл сборки от стороннего производителя

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

Ссылки на проекты

Допустим, у вас имеется проект Visual Studio, например, командный проект, содержащий код общей библиотеки, который используется несколькими командными проектами. Вы можете управлять им как изнутри, так и при помощи отдельного командного проекта.

На рис.6.1 показано, как выглядит структура папок системы управления исходным кодом TFS во втором случае.

Рис. 6.1. Cтруктура папок общего проекта Common

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

• ветвление;
• сопоставление рабочей области.

Ветвление

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

Синхронизация изменений исходного кода выполняется в процессе слияния ветвей, и решение об извлечении изменений из общего исходного кода становится более явным и управляемым, хотя и приводит к дополнительным накладным расходам. Кроме того, упрощается использование Team Build: сопоставление производится на серверной стороне, а сопоставление на клиенте, которое нужно было бы копировать на сервер сборки, отсутствует.

Допустим, у вас есть два командных проекта TeamProject1 и $Common, причем проект $Common является совместно используемым. Вы создаете ветвь, ведущую из общего расположения в проект, где есть ссылка на него. Структура папок TFS должна быть похожа на структуру, показанную на рис.6.2.

Рис. 6.2. Использование ветвления

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

Примерная структура папок рабочей области на стороне клиента показана на рис.6.3.

Рис. 6.3. Сопоставление рабочей области на клиентской стороне

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

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

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

Допустим, у вас есть два командных проекта $MyTeamProject и $Common, причем $Common - проект с общим исходным кодом. Эти проекты совместно используют общий путь на клиентском жестком диске. Структура папок рабочей области на стороне клиента будет похожа на структуру, показанную на рис.6.4.

Рис. 6.4. Использование сопоставления рабочей области

Сопоставление рабочей области выглядит примерно так:

Дополнительную информацию вы найдете в статье "Working with multiple team projects in Team Build" по адресу http://blogs.msdn.com/manishagarwal/ archive/2005/12/22/506635.aspx .