Руководства

Ветвление

• Используйте новые типы командной сборки при создании неполной ветви.
• Изменяйте пути к решениям в файлах TFSBuild.proj при создании полной ветви.

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

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

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

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

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

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

• Дополнительную информацию об обновлении типа сборки вы найдете в статье "How to: Update Build Types on Branched Team Projects" по адресу http://msdn2.microsoft.com/en-us/library/ms252500(VS.80).aspx.

Изменяйте пути к решениям в файлах TFSBuild.proj при создании полной ветви

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

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

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

• Дополнительную информацию об обновлении типа сборки вы найдете в статье "How to: Update Build Types on Branched Team Projects" по адресу http://msdn2.microsoft.com/en-us/library/ms252500(VS.80).aspx.

Политики возврата после правки

• Используйте политики возврата после правки для улучшения качества кода.
• Используйте политики возврата после правки, чтобы связать рабочие элементы со сборкой.

Используйте политики возврата после правки для улучшения качества кода

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

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

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

• Дополнительную информацию о создании и применении пользовательских политик возврата после правки вы найдете в разделе "Как создать пользовательскую политику возврата после правки в Visual Studio Team Foundation Server" этой книги.
• Чтобы узнать о настройке политики возврата после правки, читайте статью "Walkthrough: Customizing Check-in Policies and Notes" по адресу http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx.
• Чтобы посмотреть пример кода, который запрещает возврат правок с определенными вариантами кодирования, читайте статью "Checkin Policy to Disallow Certain Patterns" по адресу http://blogs.msdn.com/jmanning/ar-chive/2006/02/02/523125.aspx.
• Чтобы посмотреть пример кода, который обязывает вводить комментарии при возврате после правки, читайте статью "Sample Checkin Policy: Make Sure the Comment Isn't Empty" по адресу http://blogs.msdn.com/ jmanning/archive/2006/01/21/515858.aspx.
• Чтобы узнать, как зарегистрировать новую политику возврата после правки, читайте статью "I've Made a New Check-In Policy! How Do I Add It?" по адресу http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx.

Используйте политики возврата после правки, чтобы связать рабочие элементы со сборкой

Существует политика возврата после правки, которая вынуждает разработчиков связывать возврат после правки с рабочим элементом.

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

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

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

• Дополнительную информацию о создании и применении пользовательских политик возврата после правки вы найдете в разделе "Как создать пользовательскую политику возврата после правки в Visual Studio Team Foundation Server " этой книги.
• Чтобы узнать о настройке политики возврата после правки, читайте статью "Walkthrough: Customizing Check-in Policies and Notes" по адресу http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx.

Непрерывная интеграция

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

Используйте непрерывную интеграцию, чтобы обеспечить быструю реакцию на возврат после правки

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

Хотя Team Foundation Server 2005 не содержит встроенного средства для непрерывной интеграции, в нем есть все необходимое для реализации собственного решения непрерывной сборки.

Дополнительную информацию о настройке непрерывных сборок в TFS вы найдете в разделе "Как настроить непрерывную сборку в Visual Studio Team Foundation Server ", где используется решение, представленное группой разработки Microsoft Visual Studio Team System (VSTS) . Решение устанавливает веб-службу, которая работает от имени учетной записи, имеющей доступ к серверу TFS. Team Foundation Server позволяет при возникновении определенного события отправлять сообщение электронной почты или вызвать веб-службу Механизм событий используется решением непрерывной интеграции для регистрации веб-службы, связанной с событием Checkin Event. Всякий раз, когда происходит возврат после правки, веб-служба инициирует запуск Team Build.

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

• Дополнительную информацию вы найдете в лекции 8 этой книги.
• Дополнительную информацию о настройке сборок по расписанию в TFS вы найдете в разделе "Как настроить плановую сборку в Visual Studio Team Foundation Server " этой книги.
• Дополнительную информацию об использовании решения непрерывной интеграции VSTS вы найдете в статье "Continuous Integration Using Team Foundation Build" по адресу http://msdn2.microsoft.com/en-us/library/ ms364045(VS.80).aspx.
• Чтобы загрузить MSI -пакет решения непрерывной интеграции VSTS, перейдите по адресу http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi.
• Дополнительную информацию по гибкой разработке ПО и непрерывной интеграции в TFS вы найдете в статье "Extend Team Foundation Server To Enable Continuous Integration" по адресу http://msdn.microsoft.com/msdn-mag/issues/06/03/TeamSystem/default.aspx.

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

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

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

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

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

• Дополнительную информацию вы найдете в лекции 8 этой книги.

Убедитесь, что периодичность сборок значительно превышает продолжительность одной сборки

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

Чтобы определить идеальный интервал времени скользящей сборки, разделите среднюю частоту возвратов после правки на длительность сборки. Например, если сборка занимает 10 минут, а возвраты после правки происходят в среднем раз в 5 минут, можно задать выполнение сборки после двух возвратов после правки, а для времени ожидания выбрать значение 10 минут. Это гарантирует завершение одной сборки до начала следующей. Если нагрузка на сервер сборки возросла, увеличьте эти значения.

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

• Дополнительную информацию вы найдете в лекции 8 этой книги.

Настройка

• Используйте послесборочный шаг для создания проекта установщика.
• Используйте MS Build Toolkit Extras для сборки приложений Microsoft .NET 1.1.
• Используйте TFSBuild.proj для изменения параметров сборки.
• Используйте досборочный шаг для сборки проекта, зависящего от другого проекта.

Используйте послесборочный шаг для создания проекта установщика

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

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

• Дополнительную информацию вы найдете в статье "Walkthrough: Configuring Team Foundation Build to Build a Visual Studio Setup Project" по адресу http://msdn2.microsoft.com/en-us/library/ms404859(VS.80).aspx.

Используйте MS Build Toolkit Extras для сборки приложений Microsoft .NET 1.1

Team Build по умолчанию не поддерживает приложения .NET 1.1. Производить сборки .NET 1.1 позволяет пакет MSBuild Extras - Toolkit for .NET 1.1 (MSBee) , но при этом потребуется обновление проектов и решений до Visual Studio 2005. Если это невозможно, используйте для компиляции приложений .NET 1.1 пользовательский послесборочный шаг. Дополнительные ресурсы

• Чтобы загрузить MSBee, обратитесь по адресу http://www.codeplex.com/ MSBee.
• Дополнительную информацию о создании послесборочных действий для сборки приложений .NET 1.1 вы найдете в блоге по адресу http://blogs. msdn.com/nagarajp/archive/2005/10/26/485368.aspx.

Используйте TFSBuild.proj для изменения параметров сборки

Чтобы изменить параметры сборки, например, сервер сборки, место накопления или папку сборки, отредактируйте файл TFSBuild.proj.

В файле TFSBuild.proj содержится множество сведений, необходимых для работы Team Build. Здесь, в частности, задается, должны ли при сборке выполняться статический анализ кода и модульные тесты. Чтобы изменить параметры сборки, отредактируйте файл TFSBuild.proj.

Редактирование файла TFSBuild.proj

1. Извлеките файл для правки.
2. Отредактируйте параметры сборки в файле.
3. Возвратите файл в систему

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

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

• Дополнительную информацию о настройке Team Foundation Build вы найдете в статье "Customizing Team Foundation Build" по адресу http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx.

Используйте досборочный шаг для сборки проекта, зависящего от другого проекта

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

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

• Дополнительную информацию вы найдете в статье "Working with multiple team projects in Team Build" по адресу http://blogs.msdn.com/manisha-garwal/archive/2005/12/22/506635.aspx.
• Дополнительную информацию о пользовательской настройке Team Foundation Build вы найдете в статье "Customizing Team Foundation Build" по адресу http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx.

Развертывание

• В больших командах устанавливайте службы сборки на отдельный сервер.

В больших командах устанавливайте службы сборки на отдельный сервер

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

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

• Чтобы загрузить Team Foundation Installation Guide или получить дополнительные сведения по установке TFS и Team Build, обращайтесь по адресу http://www.microsoft.com/downloads/details.aspx?FamilyId=E54BF6FF026B-43A4-ADE4-A690388F310E&displaylang=en.

Производительность

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

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

По умолчанию перед извлечением дерева исходного кода, необходимого для сборки, Team Build очищает папку, используемую для выполнения сборки. Кроме того, Team Build удаляет и повторно инициализирует рабочую область, используемую для извлечения исходного кода. Если объем исходного кода, необходимого для сборки, достаточно велик и сервер сборки установлен отдельно от TFS -сервера, извлечение исходного кода может занять много времени. Чтобы повысить производительность, настройте Team Build так, чтобы извлекался только тот исходный код, который изменился с момента последней сборки. Для этого вам потребуется установить несколько значений в файле TFSBuild.proj:

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

Выполнение инкрементной сборки

1. Создайте новый тип сборки, который будет представлять инкрементную сборку.
2. Извлеките для правки файл TFSBuild.proj, связанный со вновь созданным типом инкрементной сборки.
3. Добавьте в TFSBuild.proj следующий раздел перед закрывающим элементом </project> :

   <PropertyGroup>
   <SkipClean>true</SkipClean>
   <SkipInitializeWorkspace>true</SkipInitializeWorkspace>
   <ForceGet>false</ForceGet> </ PropertyGroup>

Эти настройки приводят к следующим результатам:

• SkipClean Значение true этого параметра гарантирует, что локальные папки сборки и исходных кодов не будут очищаться при сборке.
• SkipInitializeWorkspace Значение true этого параметра означает, что сборка на затронет текущую рабочую область для компьютера сборки.
• ForceGet Присвоение значения false этому параметру приводит к тому, что при сборке будут извлекаться не все исходные коды рабочей области, а только измененные коды.

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

• Дополнительную информацию вы найдете в разделе "Практические рекомендации: Team Build " этой книги.
• Дополнительную информацию о конфигурировании инкрементной сборки вы найдете в статье "How to: Configure Team Foundation Build for an Incremental Build" по адресу http://msdn2.microsoft.com/en-us/library/ aa833876(VS.80).aspx.

Избегайте синхронизации излишних папок при сборке

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

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

Например, по умолчанию новый проект сопоставляется с папкой $/Team-Project. Если все файлы исходных кодов находятся в папке $/TeamProject/ foo/bar/foobar/sources, вам следует сопоставлять только эту папку.

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

Сокрытие папки

1. Извлеките для правки файл WorkspaceMapping.xml.
2. Добавьте в файл записи о сокрытии.
3. Верните файл WorkspaceMapping.xml в систему управления исходным кодом.

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

<Mappings>
<InternalMapping ServerItem="$/MyTeamProject"  LocalItem="c:\projects\ teamproject" Type="Map" />
<InternalMapping ServerItem="$/MyTeamProject/documentation" Type="Cloak" /> </Mappings>

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

• Дополнительную информацию о сокрытии папок в рабочей области вы найдете в статье "How to: Cloak and Decloak Folders in a Workspace" по адресу http://msdn2.microsoft.com/en-us/library/ms181378(VS.80).aspx.
• Дополнительную информацию об исключении папок при командной сборке вы найдете в статье "How to make 'Team Build' skip getting certain folders?" по адресу http://blogs.msdn.com/manishagarwal/archive/2005/10 /13/480584.aspx.
• Дополнительную информацию о схеме WorkspaceMapping вы найдете в статье "Schema for the WorkspaceMapping.xml file" по адресу http://blogs. msdn.com/buckh/archive/2007/02/28/schema-for-the-workspacemapping-xml-file.aspx.

Используйте рабочие области, чтобы запретить извлечение для правки нежелательных файлов и проектов в Team Build

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

Большой командный проект, как правило, содержит несколько решений Visual Studio, каждое из которых используется для сборки отдельных частей проекта. Создавая тип командной сборки, вы указываете решение, которое будет использоваться при сборке. Если вы зададите файл решения без указания рабочей области, перед выполнением сборки Team Build извлечет все исходные коды командного проекта.

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

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

• Дополнительную информацию о создании типа командной сборки вы найдете в статье "Walkthrough: Creating a Build Type in Team Foundation Build" по адресу http://msdn2. microsoft. com/en -us/library/ms181286 (VS. 80).aspx.
• Подробнее о том, почему Team Build извлекает для правки весь исходный код рабочей области, читайте в статье "Why does Team Build sync all sources in spite of my selecting only a subset of solutions?" по адресу http:// blogs.msdn.com/anutthara/archive/2005/12/07/500923.aspx.

Повышайте производительность за счет использования нескольких компьютеров

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

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

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

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

• Дополнительную информацию вы найдете в лекции 7 этой книги.