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

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

Как использовать данную статью

Данная статьярассказывает об управлении зависимостями в среде коллективной разработки. Ее можно прочитать от начала и до конца или ознакомиться лишь с разделом, рассматривающим конкретный вопрос управления зависимостями. Раздел «Сценарии и решения» поможет понять, какие вообще сценарии управления зависимостями существуют в среде коллективной разработки. Этот раздел является трамплином для перехода к следующим разделам, подробно рассматривающим каждый из сценариев.

• Раздел «Использование проектов» рассказывает о том, как работать со ссылками на другие проекты, как внутренними, так и внешними по отношению к текущему групповому проекту.
• Раздел «Использование сборок сторонних производителей» рассказывает, как работать со ссылками на сборки сторонних производителей, исходным кодом которых вы не располагаете.
• Раздел «Использование Веб-сервисов» рассказывает, как работать со ссылками на совместно используемые Веб-сервисы в среде коллективной разработки.
• Раздел «Использование баз данных» рассказывает, как соединяться с базами данных и использовать их в среде коллективной разработки.

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

Обычно реализуются следующие сценарии управления зависимостями:

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

Использование сборок, сформированных другим проектом в том же решении

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

Использование сборок, сформированных проектами других решений

Существует два варианта использования сборки, сформированной проектом в другом решении Visual Studio:

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

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

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

Использование сборки из другого группового проекта

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

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

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

При ветвлении возникают дополнительные издержки на слияние, они влияют на решение, использовать ли обновления в виде бинарных файлов или в виде исходного кода.

Использование сборки стороннего производителя

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