Заметки консультанта

Шамрай Александр Владимирович

Рекомендации: Team Build

<< Назад

Область применения

•      Microsoft® Visual Studio® 2005 Team Foundation Server (TFS)

•      Microsoft Visual Studio Team System

Содержание

Стратегия

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

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

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

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

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

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

Ветвление

•      Использование новых типов сценариев сборки при неполном ветвлении.

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

Политики регистрации изменений

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

•      Использование политик регистрации изменений для ассоциирования рабочих элементов со сборкой.

Сборки в процессе непрерывной интеграции

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

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

•      Обеспечение достаточного для завершения сборки интервала выполнения скользящих сборок.

Настройка

•      Использование специального этапа после сборки для сборки проекта создания пакета установки приложения.

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

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

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

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

•      Установка сервисов сборки на отдельном сервере для больших групп.

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

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

•      Как избежать синхронизации ненужных папок при сборке.

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

•      Использование нескольких серверов сборки для повышения производительности сборки.

Проекты

•      Как избежать зависимостей между групповыми проектами.

•      Использование ссылок на проекты, а не на файлы.

•      Использование проекта развертывания Веб-приложения.

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

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

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

Плановые сборки

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

Разработка через тестирование

•      Проведение анализа кода каждой сборки.

•      Выполнение автоматизированного тестирования каждой сборки.

•      Если сборка не проходит автоматизированные тесты, считать ее дефектной.

Рабочие элементы

•      Использование рабочих элементов для отслеживания дефектов сборки.

Стратегия

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

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

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

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

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

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

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

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

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

Team Build в Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) не поддерживает выполнение плановых сборок из пользовательского интерфейса. Для запуска сборок в заданное время можно использовать Microsoft Windows® Task Scheduler и утилиту командной строки TFSBuild.

Примечание: Пользователи TFS 2008 могут планировать сборки прямо в Visual Studio. Для редактирования описания типа сценария сборки необходимо щелкнуть правой кнопкой мыши описание сборки под узлом Builds в Team Explorer, выбрать Edit Build Definition, щелкнуть Trigger и задать расписание сборки.

Чтобы создать плановую сборку

1.    Создайте следующую командную строку TFSBuild:

TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>

2.    Поместите командную строку в командный файл.

3. Создайте Windows Scheduled Task, которая будет выполнять командный файл с заданной периодичностью.

Дополнительные источники

•      Подробнее о настройке плановых сборок в Team Build рассказывает Глава 9 «Настройка плановых сборок в Team Build» данного руководства.

•      Подробнее о настройке плановых сборок в TFS рассказывает раздел «Как: настроить плановую сборку в Visual Studio Team Foundation Server» данного руководства.

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

Используйте сборки в процессе непрерывной интеграции (CI-сборки), чтобы обеспечить группе разработки быструю обратную связь по любым изменениям, приводящим к сбоям, и по качеству сборки после каждой регистрации изменений. Таким образом, группа разработки сможет быстро устранять возникающие проблемы и повышать качество кода.

Team Foundation Server 2005 не обеспечивает стандартного CI-решения, но предлагает разработчику инфраструктуру для реализации собственного решения CI-сборки.

Подробнее о настройке CI-сборки в TFS рассказывается в разделе «Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server». В нем используется решение, предоставленное группой разработки Microsoft Visual Studio Team System (VSTS). Это решение устанавливает Веб-сервис, который выполняется под учетной записью, имеющей доступ к серверу TFS. Team Foundation Server при возникновении определенных событий может посылать сообщение электронной почты или вызывать Веб-сервис. Такой механизм событий используется решением CI для подписки Веб-сервиса на событие CheckinEvent. Таким образом, каждый раз при возникновении события регистрации изменений Веб-сервис запускает Team Build.

Примечание: Пользователи TFS 2008 могут конфигурировать процесс непрерывной интеграции из Visual Studio. Для редактирования описания типа сценария сборки необходимо щелкнуть правой кнопкой мыши описание сборки под узлом Builds в Team Explorer, выбрать Edit Build Definition, щелкнуть Trigger и задать активацию сборок по событию регистрации изменений.

Дополнительные источники

Развернутая информация представлена в Главе 8 «Как настроить процесс непрерывной интеграции с помощью Team Build» данного руководства.

•      Подробнее о настройке Cl-сборки рассказывает раздел «Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server» данного руководства.

•      Подробнее об использовании Cl-решения VSTS рассказывается в статье «Continuous Integration Using Team Foundation Build» по адресу http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx.

•      Скачать пакет установки (MSI) Cl-решения VSTS можно по адресу http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi.

•      Более подробно о гибкой разработке и CI в TFS можно прочитать в статье «Extend Team Foundation Server To Enable Continuous Integration» по адресу http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx.

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

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

•      Продолжительность сборки проекта в минутах

•      Средняя частота регистраций изменений в минутах

•      Временное окно, когда изменения регистрируются особенно интенсивно

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

Дополнительные источники

•      Подробнее об этом рассказывается в Главе 8 «Как настроить процесс непрерывной интеграции с помощью Team Build» данного руководства.

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

Во избежание сбоев при сборке активную разработку следует вести в ветви Development, а интеграционную сборку выполнять в ветви Main.

Вот пример структуры ветвления после создания ветви Development:

•      Development — Ветвь разработки

о Source

•      Main — Ветвь интеграции

о Source — исходный код

о Other Assets folders — папки других ресурсов

Рекомендации по работе с ветвью выпускаемой версии:

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

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

•      Права доступа при работе с ветвями:

о Разработчики, ответственные за слияние и интеграцию, должны иметь право на чтение/запись в ветвь Main, но все остальные — только право на чтение.

о Право на чтение/запись в ветвь Dev должно быть у всех.

•      Частота сборки:

о Ежедневные сборки для ветви Main. о Cl-сборки для ветви Dev.

•     Тестирование:

о Для ветви Main выполняются интеграционное тестирование, тестирование производительности и безопасности.

о Для ветви Dev выполняется функциональное и тестирование для получения быстрой обратной связи.

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

Дополнительные источники

•      Подробнее о выборе стратегии ветвления и слияния рассказывает Глава 5 «Выбор стратегии ветвления и слияния» данного руководства.

•      Вводную информацию по ветвлению и слиянию можно найти в материале «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/msl81425(VS.80).aspx.

•      Более подробно о слиянии рассказывает статья «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

•     Дополнительное описание процесса ветвления и слияния в Visual Studio 2005 можно найти в статье «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/msl81423(VS.80).aspx.

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

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

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

Чтобы активировать политику анализа кода при регистрации изменений для группового проекта, щелкаем правой кнопкой мыши групповой проект в Team Explorer, выбираем Team Project Settings (Настройки группового проекта) и щелкаем Source Control (Система контроля версий). Выбираем вкладку Check-in Policy (Политика регистрации изменений), нажимаем Add и выбираем и конфигурируем соответствующую политику.

Дополнительные источники

•      Подробнее о создании и использовании специальной политики регистрации изменений рассказывает раздел «Как: Создавать специальные политики регистрации изменений в коде в Visual Studio Team Foundation Server» данного руководства.

•      О том, как настраивать политику регистрации изменений, расскажет статья «Walkthrough: Customizing Check-in Policies and Notes» (По шагам: как настроить политики регистрации изменений и комментарии к ним) по адресу http://msdn2.microsoft.com/en-us/library/msl81281(VS.80).aspx.

•      Увидеть пример кода, который не допустит регистрации файлов, содержащих определенные шаблоны, можно в статье «Checkin Policy to Disallow Certain Patterns» (Политика регистрации изменений, запрещающая определенные шаблоны) по адресу http://blogs.msdn.com/imanning/archive/2006/02/02/523125.aspx.

•      Увидеть пример кода, который требует обязательного ввода комментариев при регистрации изменений, можно в статье «Sample Checkin Policy: Make Sure the Comment Isn’t Empty» (Пример политики регистрации изменений: гарантируем непустой комментарий) по адресу http://blogs.msdn.com/imanning/archive/2006/01/21/515858.aspx.

•      Как добавить новую политику регистрации изменений можно узнать в статье «I’ve Made a New Check-In Policy! How Do I Add It?» (Я создал новую политику регистрации изменений! Как ее добавить?) по адресу http://blogs.msdn.com/imanning/archive/2006/02/07/526778.aspx.

Использование уведомлений о ходе сборки для оповещения о завершении сборки

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

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

Дополнительные источники

•      Подробнее об уведомлениях о завершении сборки рассказывается в статье «How to: Receive Build Notification E-Mail» (Как: настроить получение сообщений о завершении сборки по электронной почте) по адресу http://msdn2.microsoft.com/en-us/librarv/msl81725(VS.80).aspx.

•     Дополнительную информацию об уведомлениях о завершении сборки можно найти в статье «How to: Add or Edit Alerts» (Как: Добавлять или редактировать уведомления) по адресу http://msdn2.microsoft.com/en-us/library/msl81335(VS.80).aspx.

Ветвление

•      Использование новых типов сценариев сборки при неполном ветвлении.

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

Использование новых типов сценариев сборки при неполном ветвлении

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

Существует два типа неполных ветвей:

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

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

При создании неполной ветви, которая не включает Team Build Types, все существующие Team Build останутся работоспособными, но для сборки кода данной ветви придется создать новый Team Build Type. Новые типы сценариев сборки создаются с помощью мастера Team Build Wizard (Мастер сценариев сборки). Вновь создаваемые типы сценариев сборки будут указывать на местоположение новой ветви, а также могут указывать на родительскую ветвь для решений, которые должны быть включены в сборку, но не имеют собственной ветви.

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

Дополнительные источники

Подробнее об обновлении типов сценариев сборки рассказывает статья «How to: Update Build Types on Branched Team Projects» (Как: Обновлять типы сценариев сборки в ветвях групповых проектов) по адресу http://msdn2.microsoft.com/en-us/library/ms252500(VS.80).aspx.

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

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

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

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

Дополнительные источники

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

Политики регистрации изменений

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

•      Использование политик регистрации изменений для ассоциирования рабочих элементов со сборкой.

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

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

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

Дополнительные источники

•      Подробнее о создании и использовании специальной политики регистрации изменений рассказывает раздел «Как: создавать специальные политики регистрации изменений в коде в Visual Studio Team Foundation Server» данного руководства.

•      О том, как настраивать политику регистрации изменений, расскажет статья «Walkthrough: Customizing Check-in Policies and Notes» по адресу http://msdn2.microsoft.com/en-us/library/msl81281(VS.80).aspx.

•      Увидеть пример кода, который не допустит регистрации файлов, содержащих определенные шаблоны, можно в статье «Checkin Policy to Disallow Certain Patterns» по адресу http://blogs.msdn.com/imanning/archive/2006/02/02/523125.aspx.

•      Увидеть пример кода, который требует обязательного ввода комментариев при регистрации изменений, можно в статье «Sample Checkin Policy: Make Sure the Comment Isn’t Empty» по адресу http://blogs.msdn.com/imanning/archive/2006/01/21/515858.aspx.

•      Как добавить новую политику регистрации изменений можно узнать в статье «I’ve Made a New Check-In Policy! How Do I Add It?» по адресу http://blogs.msdn.com/imanning/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/msl81281(VS.80).aspx.

Сборки в процессе непрерывной интеграции

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

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

•     Обеспечение достаточного для завершения сборки интервала выполнения скользящих сборок.

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

Используйте сборки в процессе непрерывной интеграции (Cl-сборки), чтобы обеспечить группе разработки быструю обратную связь по любым изменениям, приводящим к сбоям, и по качеству сборки после каждой регистрации изменений. Таким образом, группа разработки сможет быстро устранять возникающие проблемы и повышать качество кода.

Team Foundation Server 2005 не обеспечивает стандартного CI-решения, но предлагает разработчику инфраструктуру для реализации собственного решения CI-сборки.

Подробнее о настройке CI-сборки в TFS рассказывается в разделе «Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server». В нем используется решение, предоставленное группой разработки Microsoft Visual Studio Team System (VSTS). Это решение устанавливает Веб-сервис, который выполняется под учетной записью, имеющей доступ к серверу TFS. Team Foundation Server при возникновении определенных событий может посылать сообщение электронной почты или вызывать Веб-сервис. Такой механизм событий используется решением CI для подписки Веб-сервиса на событие CheckinEvent. Таким образом, каждый раз при возникновении события регистрации изменений Веб-сервис запускает Team Build.

Примечание: Пользователи TFS 2008 могут конфигурировать процесс непрерывной интеграции из Visual Studio. Для редактирования описания типа сценария сборки необходимо щелкнуть правой кнопкой мыши описание сборки под узлом Builds в Team Explorer, выбрать Edit Build Definition, щелкнуть Trigger и задать активацию сборок по событию регистрации изменений.

Дополнительные источники

•      Развернутая информация представлена в Главе 8 «Как настроить процесс непрерывной интеграции с помощью Team Build» данного руководства.

•      Подробнее о настройке Cl-сборки рассказывает раздел «Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server» данного руководства.

•      Подробнее об использовании Cl-решения VSTS рассказывается в статье «Continuous Integration Using Team Foundation Build» по адресу http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx.

      Скачать пакет установки (MSI) Cl-решения VSTS можно по адресу http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi.

•      Более подробно о гибкой разработке и CI в TFS можно прочитать в статье «Extend Team Foundation Server To Enable Continuous Integration» по адресу http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx.

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

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

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

•      Продолжительность сборки проекта в минутах

•      Средняя частота регистраций изменений в минутах

•      Временное окно, когда изменения регистрируются особенно интенсивно

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

Дополнительные источники

•      Подробнее об этом рассказывается в Главе 8 «Как настроить процесс непрерывной интеграции с помощью Team Build» данного руководства.

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

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

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

Дополнительные источники

Подробнее о CI-сборках рассказывается в Главе 8 «Как настроить процесс непрерывной интеграции с помощью Team Build» данного руководства.

Настройка

•     Использование специального этапа после сборки для сборки проекта создания пакета установки приложения.

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

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

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

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

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

Дополнительные источники

•     Подробнее смотрите в статье «Walkthrough: Configuring Team Foundation Build to Build a Visual Studio Setup Project» (По шагам: Конфигурирование Team Foundation Build для сборки проекта создания пакета установки приложения Visual Studio) по адресу http://msdn2.microsoft.com/en-us/library/ms404859(VS.80).aspx.

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

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

Дополнительные источники

•     Скачать MSBee можно по адресу http://www.codeplex.com/MSBee.

•     Подробнее о создании специального этапа после сборки для компиляции приложения .NET 1.1 application рассказывается в блоге Нагараджу по адресу 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» (Настройка 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/manishagarwal/archive/2005/12/22/506635.aspx.

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

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

•     Установка сервисов сборки на отдельном сервере для больших групп.

Установка сервисов сборки на отдельном сервере для больших групп

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

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

Дополнительные источники

•     Скачать «Team Foundation Installation Guide» и получить более подробную информацию об установке TFS и Team Build можно по адресу http://www.microsoft.com/downloads/details.aspx?Familyld=E54BF6FF-026B-43A4-ADE4-A690388F310E&displaylang=en.

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

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

•     Как избежать синхронизации ненужных папок при сборке.

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

•     Использование нескольких серверов сборки для повышения производительности сборки.

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

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

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

•     Запретить Team Build очищать локальную папку сборки и папку исходного кода.

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

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

Для выполнения инкрементной сборки

1. Создается новый тип сценария сборки, представляющий инкрементную сборку.

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

3.     В файле TFSBuild.proj непосредственно перед закрывающим элементом </project> добавляется следующий раздел <PropertyGroup>:

<PropertyGroup>

<SkipClean>true</SkipClean>

<SkipInitializeWorkspace>true</SkipInitializeWorkspace>

<ForceGet>false</ForceGet> </ PropertyGroup>

Эти настройки обеспечивают следующее:

•      SkipClean. Значение true для SkipClean (Пропустить очистку) гарантирует, что при сборке не будут вычищаться локальная папка сборки и папка исходного кода.

•      SkiplnitializeWorkspace. Значение true для SkiplnitializeWorkspace (Пропустить возвращение рабочего пространства в исходное состояние) гарантирует, что при сборке существующее рабочее пространство останется неизменным.

•      ForceGet. Значение false для ForceGet (Принудительное получение) гарантирует, что в сборке будет участвовать только обновленный исходный код, а не весь исходный код рабочего пространства.

Дополнительные источники

•      Более подробную информацию по этому вопросу можно найти в разделе «Краткие практические рекомендации — Team Build» данного руководства.

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

Как избежать синхронизации ненужных папок при сборке

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

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

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

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

Для сокрытия папок

1.   Версия файла WorkspaceMapping.xml изымается из системы контроля версий.

2.   В этот файл добавляются соответствующие записи для сокрытия.

3.   Файл WorkspaceMapping.xml возвращается в систему контроля версий и внесенные в него изменения регистрируются.

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

<Mappings>

<InternalMapping ServerItem=»$/MyTeamProject» LocalItem=»c:\projects\teamproject” Type=»Map» />

<InternalMapping ServerItem=»$/MyTeamProject/documentation» Type=»Cloak» /> </Mappings>

Примечание: Пользователи TFS 2008 могут конфигурировать отображения рабочего пространства прямо в Visual Studio. Для редактирования описания типа сценария сборки необходимо щелкнуть правой кнопкой мыши описание сборки под узлом Builds в Team Explorer, выбрать Edit Build Definition, щелкнуть Workspace (рабочее пространство) и редактировать настройки отображения рабочего пространства. Настройки отображения рабочего пространства больше не хранятся в WorkspaceMapping.xml.

Дополнительные источники

•      Более подробную информацию о сокрытии папок в рабочем пространстве можно найти в статье «How to: Cloak and Decloak Folders in a Workspace» (Как: выполнять сокрытие и отмену сокрытия папок в рабочем пространстве) по адресу http://msdn2.microsoft.com/en-us/librarv/msl81378(VS.80).aspx.

•      Подробнее о том, как сделать так, чтобы Team Build не включал папки в сборку, рассказывается в статье «How to make ‘Team Build’ skip getting certain folders?» (Как заставить ‘Team Build’ не включать определенные папки?) по адресу http://blogs.msdnxom/manishagarwal/archive/2005/10/13/480584.aspx.

•      О схеме WorkspaceMapping рассказывается в статье «Schema for the WorkspaceMapping.xml file» (Схема файла WorkspaceMapping.xml) по адресу

http://blogs.msdn.com/buckh/archive/2007/02/28/schema-for-the-workspacemapping-xml-file.aspx.

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

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

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

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

Дополнительные источники

•      Подробнее о создании Team Build Type рассказывает статья «Walkthrough: Creating a Build Type in Team Foundation Build» (По шагам: создание типа сценария сборки в 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?» (Почему Team Build синхронизирует весь исходный код, несмотря на то, что я выбираю только подмножество решений?) по адресу http://blogs.msdn.com/anutthara/archive/2005/12/07/500923.aspx.

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

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

Сборка может занимать много времени, особенно если это сборка большого проекта. При использовании CI-сборок или частых плановых сборок есть вероятность, что сервер сборки не справится с возложенным на него объемом работ.

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

Дополнительные источники

•     Подробнее об этом рассказывается в Главе 7 «Team Build» данного руководства.

Проекты

•     Как избежать зависимостей между групповыми проектами.

•     Использование ссылок на проекты, а не на файлы.

•     Использование проекта развертывания Веб-приложения.

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

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

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

Как избежать зависимостей между групповыми проектами

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

Дополнительные источники

•     Подробнее о создании рабочего пространства рассказывается в статье «How to: Create a Workspace» по адресу http://msdn2.microsoft.com/en-us/library/msl81384(VS.80).aspx.

•     Больше информации о редактировании рабочего пространства можно найти в статье «How to: Edit a Workspace» (Как: редактировать рабочее пространство) по адресу http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx.

•     О ветвлении боле подробно рассказывается в статье «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81425(VS.80).aspx.

Использование ссылок на проекты, а не на файлы

Если необходимо сослаться на другую сборку в рамках одного решения Visual Studio, следует использовать ссылку на проект Visual Studio. Используя ссылки на проекты, мы

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

Дополнительные источники

•      Подробнее о ссылках на проекты рассказывает статья «Project References» по адресу http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx.

Использование проекта развертывания Веб-приложения

Проекты развертывания Веб-приложений ассоциированы с проектом Веб-сайта или проектом Веб-приложения Visual Studio. Они позволяют управлять настройками сборки и многими другими настройками, свойственными Веб-приложениям ASP.NET. Например, проект развертывания Веб-приложения обеспечивает простой доступ к файлу Web.config, строкам соединения и виртуальным каталогам и упрощает развертывание компилированного Веб-приложения на сервере публикации в Web/Intranet.

Дополнительные источники

•      За дополнительной информацией обращайтесь к статье «Visual Studio 2005 Web Deployment Projects» (Проекты развертывания Веб-приложений Visual Studio 2005) по адресу http://msdn2.microsoft.com/en-us/asp.net/aa336619.aspx.

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

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

Дополнительные источники

•      Подробнее об этом рассказывается в Главе 3 «Структурирование проектов и решений в системе контроля версий» данного руководства.

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

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

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

Дополнительные источники

Более подробно об этом рассказывает Глава 3 «Структурирование проектов и решений в системе контроля версий» данного руководства.

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

При работе над очень большим решением, включающим десятки проектов, может возникнуть проблема с его масштабируемостью. В таком случае следует разбить приложение на несколько решений, но при этом не создавать главного решения для всего приложения, потому что все ссылки внутри решений являются ссылками на проекты. Ссылки на проекты вне решений (например, библиотеки сторонних производителей или проекты из другого составляющего решения) являются ссылками на файлы. Это означает, что без «главного» решения можно обойтись. Вместо него должен использоваться сценарий, который понимает порядок сборки решений. Одна из задач обслуживания структуры с несколькими решениями — гарантированно обеспечить невозможность создания циклических ссылок между решениями. Эта структура требует сложных сценариев сборки и явного отображения зависимостей. При такой структуре нельзя осуществить сборку всего приложения в Visual Studio. Это делается непосредственно из TFS Team Build или MSBuild.

Дополнительные источники

•     Более подробно об этом рассказывает Глава 3 «Структурирование проектов и решений в системе контроля версий» данного руководства.

Плановые сборки

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

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

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

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

Team Build в Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) не поддерживает выполнение плановых сборок из пользовательского интерфейса. Для запуска сборок в заданное время можно использовать Microsoft Windows® Task Scheduler и утилиту командной строки TFSBuild.

Чтобы создать плановую сборку

1.    Создайте следующую командную строку TFSBuild:

TfsBuild start «TeamFoundationServer» «TeamProject» «BuildTypeName»

2.     Поместите командную строку в командный файл.

3.    Создайте Windows Scheduled Task (Плановую задачу Windows), которая будет выполнять командный файл с заданной периодичностью.

Примечание: Пользователи TFS 2008 могут планировать сборки прямо в Visual Studio. Для редактирования описания типа сценария сборки необходимо щелкнуть правой кнопкой мыши описание сборки под узлом Builds в Team Explorer, выбрать Edit Build Definition, щелкнуть Trigger и задать расписание сборки.

Дополнительные источники

•      Более подробную информацию можно найти в Главе 9 «Настройка плановых сборок в Team Build» данного руководства.

•      Подробнее о настройке плановых сборок рассказывает раздел «Как: настроить плановую сборку в Visual Studio Team Foundation Server» данного руководства.

Разработка через тестирование

•      Проведение анализа кода каждой сборки.

•      Выполнение автоматизированного тестирования каждой сборки.

•      Если сборка не проходит автоматизированные тесты, считать ее дефектной.

Проведение анализа кода каждой сборки

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

Включить анализ кода в сценарий сборки можно двумя способами: установить флажок code analysis (анализ кода) в мастере Team Build Type при создании нового Team Build Type или внести изменения в файл TFSBuild.proj после создания типа сценария сборки.

Как включить анализ кода посредством файла TFSBuild.proj:

•      Если требуется, чтобы анализ кода выполнялся для всех проектов, независимо от их настроек, тег <RunCodeAnalysis> (выполнять анализ кода) должен иметь значение Always (всегда).

•      Если анализ кода для каждого проекта должен выполняться соответственно настройкам проекта, тегу <RunCodeAnalysis> присваивается значение Default (по умолчанию).

Дополнительные источники

•      Более подробно об автоматическом анализе кода в ходе сборки рассказывается в разделе «Как: с помощью Team Build автоматически выполнять анализ кода в Visual Studio Team Foundation Server» данного руководства.

•      Подробнее об инструментах анализа кода рассказывает статья «Guidelines for Using Code Analysis Tools» (Рекомендации по использованию инструментальных средств анализа кода) по адресу http://msdn2.microsoft.com/en-us/library/msl82023(VS.80).aspx.

Выполнение автоматизированного тестирования каждой сборки

Автоматизированные тесты обеспечат автоматическое получение обратной связи по качеству сборки после каждой сборки. Создать список тестов и ассоциировать его со сборкой можно, используя Visual Studio Test Edition или Visual Studio Team Suite. Чтобы выполнять автоматизированные тесты на сервере сборки, на нем должны быть установлены Visual Studio Developer Edition, Visual Studio Test Edition или Visual Studio Team Suite.

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

•     Тесты не должны оставлять после себя выполняющихся процессов.

•     Тесты не должны добавлять, удалять или изменять файлы без возвращения их в исходное состояние.

•     Тесты не должны добавлять, удалять или изменять записи реестра без возвращения их в исходное состояние.

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

Чтобы выполнять автоматизированные тесты как часть процесса Team Build

1.    Создайте один или более автоматизированных тестов, которые будут выполняться со сборкой.

2.    С помощью Test Manager (менеджер тестов) создайте Test List (список тестов).

3.     В Test Manager сгруппируйте тесты в новый Test List, перемещая их методом drag-and-drop из Test View (окно отображения тестов) в Test List.

4.    Создайте новый Team Build Type.

5.    Установите флажок, чтобы автоматизированные тесты выполнялись.

6.     Выберите проект тестирования, в рамках которого были созданы ваши тесты и список тестов.

7.     Выберите список тестов, который хотите выполнять.

Дополнительные источники

•      Подробнее об автоматически выполняющихся тестах верификации сборки рассказывает статья «How to: Configure and Run Build Verification Tests (BVTs)» (Как: конфигурировать и выполнять тесты верификации сборки (Build Verification Tests, BVT)) по адресу http://msdn2.microsoft.com/en-us/library/ms182465(VS.80).aspx.

•      О выполнении автоматизированных тестов сборки без Visual Studio Test Edition или файла VSMDI подробно рассказывается в статье «How to run tests in a build without test metadata files and test lists (.vsmdi files)» (Как выполнять тесты в сборке без файлов метаданных тестов и списков тестов (файлов .vsmdi)) по адресу http://blogs.msdn.com/buckh/archive/2006/11/04/how-to-run-tests-without-test-metadata-files-and-test-lists-vsmdi-files.aspx.

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

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

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

Чтобы завершить сборку сбоем при непрохождении теста

1.   Откройте файл Microsoft.TeamFoundation.Build.targets из каталога Program Files\MSBuild\Microsoft\VisualStudio\v8.0\TeamBuild.

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

3.   Скопируйте цель RunTestWithConfiguration (Выполнять тест с конфигурацией) из Microsoft.TeamFoundation.Build.targets в самый конец файла TFSBuild.proj, непосредственно перед закрывающим тегом </Project>.

4.   Измените значение атрибута ContinueOnError (Продолжать в случае ошибки) с true на false.

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

5.   Если требуется создавать рабочий элемент при сбое сборки, измените RunTestWithConfiguration, добавив элемент OnError непосредственно перед закрывающим тегом </Target>. Элемент OnError должен иметь следующий вид:

<OnError ExecuteTargets=»CreateWorkItem;»/>

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

Microsoft.TeamFoundation.Build.targets. Таким образом, изменится поведение всех типов сценариев сборки.

Предлагаемое выше решение легко реализовать, но нет гарантии, что оно будет применимо в будущих версиях Visual Studio. О том, как реализовать решение, которое гарантированно будет работать после перехода на более новую версию, рассказывается в записи блога Аарона Холлберга (Aaron Hallberg) «Determining Whether Tests Passed in Team Build» (Как определить, выполняются ли тесты при сборке группового проекта) по адресу

http://blogs.msdn.com/aaronhallberg/archive/2006/09/21/determining-whether-tests-passed-in-team-build.aspx.

Дополнительные источники

•      Более подробную информацию о том, как настроить сборку, чтобы при непрохождении теста создавался рабочий элемент, можно найти в статье «Create Workitems for Test Failures in TeamBuild» (Создание рабочих элементов для непройденных тестов при сборке группового проекта) по адресу http://blogs.msdnxom/nagaraip/archive/2005/10/14/481290.aspx.

•      Подробнее о решении, которое гарантированно будет применимо и в более новых версиях Visual Studio, рассказывает статья «Determining Whether Tests Passed in Team Build» по адресу

http://blogs.msdn.com/aaronhallberg/archive/2006/09/21/determining-whether-tests-passed-in-team-build.aspx.

Рабочие элементы

• Использование рабочих элементов для отслеживания дефектов сборки.

Использование рабочих элементов для отслеживания дефектов сборки

Если Team Build дает сбой, он автоматически создает рабочий элемент для отслеживания этого сбоя. По умолчанию рабочему элементу назначается статус ‘Active’ (активный) и дается информативное имя, которое сообщит, что элемент соответствует сбою сборки. Для решения проблемы и исправления сборки этот рабочий элемент следует передать ответственному разработчику или руководителю, ответственному за сборку.

Задача сборки в файле TFSBuild.proj, определяющая этот рабочий элемент, выглядит следующим образом:

<!— Создание Workltem для сбоя сборки —> <CreateNewWorkItem

Buildld=»$(BuildNumber)» Description=»$(WorkltemDescription)» TeamProject=»$(TeamProject)»

TeamFoundationServerUrl=»$(TeamFoundationServerUrl)» Title=»$(WorkltemTitle)»

WorkItemFieldValues=»$(WorkltemFieldValues)» WorkItemType=»$(WorkltemType)» ContinueOnError=»true» />

Изменяя поле WorkltemFieldValues, можно настроить созданный рабочий элемент (например, назначить его конкретному разработчику или задать степень серьезности и приоритет).

Дополнительные источники

•      Подробнее о настройке рабочего элемента для отслеживания сбоя сборки рассказывает статья «Team Foundation Build Tasks» (Задачи Team Foundation Build) по адресу http://msdn2.microsoft.com/en-us/library/ms243778(vs.80).aspx.

Дополнительные источники по сборке

•      Больше общей информации о Team Build можно найти в статье «Overview of Team Foundation Build» по адресу http://msdn2.microsoft.com/en-us/library/msl81710(VS.80).aspx.

<< Назад

Реклама
 
%d такие блоггеры, как: