Обзор

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

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

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

Эта лекция адресована тем, кто участвует в управлении, поддержке и работе над крупномасштабными проектами. Рекомендации по работе с большими проектами можно также найти в лекциях 3, 5 и 7. В этой лекции все рекомендации по работе над большими проектами сведены воедино.

Логическая последовательность операций в больших проектах

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

увеличить изображение
Рис. 10.1. Сценарий работы с большим проектом

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

Рекомендации по управлению версиями

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

Рис. 10.2. Подход с использованием нескольких решений

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

Одна из главных задач при обслуживании структуры с несколькими решениями - обеспечить отсутствие циклических ссылок между решениями, что требует сложных сценариев сборки и явного отображения зависимостей. При такой структуре невозможно целиком собрать приложение в Visual Studio ; приходится прибегать к TFS Team Build.

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

Рекомендации по ветвлению и слиянию

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

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

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

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

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

Если в вашей команде возникли эти проблемы, подумайте об уменьшении глубины структуры ветвления. Ниже приведен пример структуры ветвления в большой группе:

My Project

• Development - контейнер для активных ветвей разработки
  • Team 1
    • Feature A - изолированная ветвь разработки
      • Source
    • Feature B - изолированная ветвь разработки
      • Source
  • Team 2
    • Feature A - изолированная ветвь разработки
      • Source
    • Feature B - изолированная ветвь разработки
      • Source
• Main - главная ветвь интеграции и сборки. Здесь сводятся воедино все изменения.
  • Source
  • Папки других ресурсов
• Releases - контейнер для выпусков
  • Release 4 - ветвь с кодом на этапе подготовки к выпуску, внесение изменений в который запрещено
    • Source
  • Release 2 - активная ветвь обслуживания
    • Source
  • Release 3 - активная ветвь обслуживания
    • Source
• Архив
  • Release 1 - Ветвь архивного хранения старой версии
    • Source

В эту структуру включены:

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

Рекомендации по выполнению сборки

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

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

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

Резюме

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

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

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

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

• Подробнее о системе управления версиями 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/ms 181384(VS.80).aspx.
• Введение в ветвление и слияние вы найдете в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80). aspx.
• Подробнее о ветвлении читайте в статье "How To - Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library/ms 181425(VS.80).aspx.
• Подробнее о слиянии читайте в статье "How To - Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library/ms181 428(VS.80).aspx.
• Подробное описание методов ветвления и слияния в Visual Studio 2005 вы найдете в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms 181423(VS.80).aspx.
• Подробнее о Team Build читайте в статье "Overview of Team Foundation Build" по адресу http://msdn2.microsoft.com/en-us/library/ms181710(vs.80). aspx.