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

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

Краткие практические рекомендации: Team Build

<< Назад

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

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

Microsoft Visual Studio Team System

Содержание Администрирование

Как обеспечить безопасность сервера сборки

Как удалить сборку

Как удалить тип сценария сборки

Как ассоциировать рабочий элемент со сборкой

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

Как с помощью политик регистрации изменений повысить качество регистрируемых изменений

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

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

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

Как определить, нужна ли скользящая сборка

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

Настройка

Как изменить номер сборки

Как настроить отображение рабочего пространства для получения и сборки части дерева исходного кода

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

Как изменить конфигурацию сборки (выпускаемая версия/отладочная версия)

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

Как установить сервер сборки

Как определить, есть ли необходимость в нескольких серверах сборки

Общее

Как с помощью Team Build выполнять сборку и развертывание приложений ASP.NET

Как с помощью Team Build выполнять сборку приложений на основе Microsoft® .NET 1.1

Как с помощью Team Build выполнять сборку проектов создания пакетов установки и развертывания

Как создать тип сценария сборки

Как создать несколько типов сценариев сборки

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

Как подписаться на получение уведомлений о сборке по электронной почте

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

Как запустить сборку

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

Как просмотреть результат сборки

Как изменить местоположение сервера сборки

Как изменить место размещения результатов сборки

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

Как изменить заявленное качество сборки

Проекты

Как использовать стратегию с одиночным решением

Как использовать стратегию с сегментированным решением

Как использовать стратегию с несколькими решениями

Создание и отображение отчетов

Как просмотреть информацию о качестве сборки

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

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

Как просмотреть рабочие элементы или дефекты, ассоциированные со сборкой

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

Как отслеживать для сборки, какие тесты были пройдены, а какие нет

Как увидеть статус сборки (результаты тестов верификации сборки)

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

Как настроить автоматический запуск сборки каждую ночь

Как выбрать для проекта частоту выполнения сборки и тип сборки

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

Как создать приемочный тест «Здравствуй, мир»

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

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

Как реализовать сбой сборки при непрохождении тестов

Администрирование

Как обеспечить безопасность сервера сборки

Как удалить сборку

Как удалить тип сценария сборки

Как ассоциировать рабочий элемент со сборкой

Как обеспечить безопасность сервера сборки

Чтобы обеспечить безопасность сервера сборки

1. Выделите под сервисы сборки отдельный сервер, не развертывайте их на одном сервере с уровнем приложений или уровнем данных Microsoft Visual Studio® 2005 Team Foundation Server (TFS).

2. Предоставьте процессу сборки доступ к каталогу сборок с правом на чтение/запись. Убедитесь, что сборка выполняется под учетной записью с правом доступа к этому каталогу.

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

4. Убедитесь, что учетная запись, используемая для выполнения сборки, является участником группы Build Services группового проекта.

Обеспечить более высокую безопасность Team Foundation Server позволит установка сервера сборки на специальном компьютере, отдельно от уровня приложений или уровня данных. Для выполнения определенных этапов развертывания или сборки могут требоваться дополнительные более широкие права доступа. Например, чтобы создать виртуальный каталог для развертывания Веб-приложения на сервере сборки, необходимо обладать правами администратора. То есть учетная запись Microsoft Windows®, под которой выполняется сборка, должна обладать такими правами. Если компьютер, на котором выполняется сборка, используется еще и как уровень приложений, это может представлять угрозу безопасности. Аналогично, если на сервере сборки размещается также и уровень данных, учетная запись, используемая для сборки, имеет доступ и может менять базы данных этого уровня.

Примечание: Из соображений безопасности нельзя добавлять учетную запись, под которой выполняется сборка, в группу SERVER\ Service Accounts. Члены этой группы обладают полными административными правами на TFS.

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

Более подробную информацию о группах TFS и правах доступа можно найти в статье «Team Foundation Server Default Groups, Permissions, and Roles» (Стандартные группы, права доступа и роли Team Foundation Server) по адресу http://msdn2.microsoft.com/en-us/library/ms253077(VS.80).aspx.

Как удалить сборку

Для удаления сборок используется инструмент командной строки TFSBuild. Для этого задается адрес сервера TFS, имя группового проекта и имя сборки; например:

TfsBuild delete http://mytfsserver:8080 myproject build20070606.4

Примечание: В TFS 2008 сборки также можно удалять из Visual Studio. Для этого в Build Explorer из списка завершенных сборок выбираем сборку, щелкаем ее правой кнопкой мыши и в выпадающем меню выбираем Delete.

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

Подробнее об удалении завершенных сборок рассказывается в статье «How to: Delete a Completed Build» (Как: Удалить завершенную сборку) по адресу http://msdn2.microsoft.com/en-us/library/aa337656(VS.80).aspx.

Более подробную информацию о команде delete предлагает статья «Delete Command (Team Foundation Build)» (Команда Delete (Team Foundation Build)), которую можно найти по адресу http://msdn2.microsoft.com/en-us/librarv/ms244360(VS.80).aspx.

Как удалить тип сценария сборки

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

Чтобы удалить существующий тип сценария сборки

1. Откройте Source Control Explorer.

2. В Source Control Explorer разверните папку своего группового проекта.

3. Разверните папку TeamBuildTypes.

4. Щелкните правой кнопкой мыши папку Team Build, представляющую тип сценария сборки, который необходимо удалить, и щелкните Delete.

5. Еще раз щелкните правой кнопкой мыши папку Team Build и затем щелкните Check In Pending Changes… (Зарегистрировать ожидающие регистрации изменения)

6. Откройте Team Explorer.

7. Щелкните правой кнопкой мыши папку Team Builds и затем щелкните Refresh (Обновить).

8. Разверните папку Team Builds и убедитесь, что тип сценария сборки удален.

Примечание: Чтобы удалить описание сборки в TFS 2008, щелкните правой кнопкой мыши описание сборки под узлом Builds в Team Explorer и выберите Delete. Файлы tfsbuild.proj и tfsbuild.rsp необходимо удалить из системы контроля версий отдельно.

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

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

Как ассоциировать рабочий элемент со сборкой

Диалоговое окно Check In (Регистрация изменений) используется, чтобы ассоциировать рабочие элементы с регистрацией изменений. При этом данные рабочие элементы будут автоматически ассоциированы со следующей сборкой.

Чтобы ассоциировать рабочий элемент со сборкой

1. Внесите в код изменения, которые хотите включить в сборку и которые будут ассоциированы с рабочим элементом.

2. Зарегистрируйте ожидающие регистрации изменения в системе контроля версий.

3. В диалоговом окне Check In щелкните Work Items (Рабочие элементы).

4. Выберите рабочий(-ие) элемент(-ы), которые хотите ассоциировать с этой регистрацией изменений.

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

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

Подробнее о регистрации ожидающих регистрации изменений рассказывает статья «How to: Check In Pending Changes», которую можно найти по адресу http://msdn2.microsoft.com/en-us/library/ms181411(VS.80).aspx.

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

• Как с помощью политик регистрации изменений повысить качество регистрируемых изменений

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

Как с помощью политик регистрации изменений повысить качество регистрируемых изменений

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

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

1. В Team Explorer щелкните правой кнопкой мыши свой групповой проект, выберите Team Project Settings и затем щелкните Source Control.

2. Выберите вкладку Check-in Policy.

3. Щелкните Add, после этого выберите и конфигурируйте политики анализа кода и тестирования.

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

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

О том, как настраивать политику регистрации изменений, рассказывает статья «Walkthrough: Customizing Check-in Policies and Notes», которую можно найти по адресуhttp://msdn2.microsoft.com/en-us/librarv/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.

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

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

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

1. В Team Explorer щелкните правой кнопкой мыши свой групповой проект, выберите Team Project Settings и затем щелкните Source Control.

2. Выберите вкладку Check-in Policy.

3. Щелкните Add, затем выберите и конфигурируйте политику регистрации изменений Work Item.

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

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

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

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

• Как автоматически выполнять сборки в процессе непрерывной интеграции

• Как определить, нужна ли скользящая сборка

• Как определить интервал выполнения скользящей сборки

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

Хотя Visual Studio 2005 Team Foundation Server не обеспечивает стандартного решения для сборки в процессе непрерывной интеграции (Continuous Integration, CI), но предлагает инфраструктуру для реализации собственного решения CI-сборки.

Чтобы настроить решение CI-сборки

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

2. Установите расширение для непрерывной интеграции. Установите CI-расширение, которое можно найти по адресу http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx.

3. Настройте расширение для непрерывной интеграции. Убедитесь, что виртуальный корневой каталог Веб-приложения CI выполняется в пуле приложений TFSAppPool. Обновите файл Web.config CI Веб-приложения, чтобы он работал с вашим сервером и сборкой, добавив следующий ключ:

<add key=»1″

value=»TeamServer=http://TFSRTM:8080;TeamProjectName=AdventureWorks;BuildType=T est Build»/>

4. Подпишитесь на событие CheckinEvent. Чтобы подписаться на событие регистрации изменений, используйте инструмент BisSubscribe.exe и следующую командную строку:

Bissubscribe /eventType CheckinEvent /address http://TFSRTM:8080/ci/notify.asmx /deliveryType Soap /domain http://TFSRTM:8080

5. Протестируйте CI-сборку. Протестируйте сборку по завершении регистрации изменений. Подождите несколько минут, чтобы сборка завершилась, и затем проверьте на странице сборок, успешно ли была завершена сборка.

6. Настройте рассылку уведомлений по электронной почте. Настройте рассылку уведомлений, чтобы информировать заинтересованные стороны о завершении сборки. Из контекстного меню группового проекта откройте диалоговое окно Project Alerts (Уведомления о ходе проекта) и установите флажок уведомления A build completes (Сборка завершена).

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

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

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

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

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

Больше информации о том, как использовать CI-решение Visual Studio Team System, можно найти в статье «Continuous Integration Using Team Foundation Build» по адресу http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx.

Скачать пакет установки (MSI) CI-решения Visual Studio Team System можно по адресу 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 минут. В этом случае на момент начала сборки предыдущая сборка будет гарантированно завершена. В случае перегрузки сервера сборки значения интервалов могут быть увеличены.

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

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

Настройка

• Как изменить номер сборки

• Как настроить отображение рабочего пространства для получения и сборки части дерева исходного кода

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

• Как изменить конфигурацию сборки (выпускаемая версия/отладочная версия)

Как изменить номер сборки

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

Чтобы номер сборки правильно отображался в интерфейсе Team Build, необходимо переопределить свойство $(BuildNumber) (номер сборки) в цели BuildNumberOverride (Замена номера сборки).

Чтобы настроить номер сборки и в сборке, и в интерфейсе Team Build

1. Переопределите $(BuildNumber) в цели BuildNumberOverride.

2. Переопределите цель BeforeCompile (Перед компиляцией) для записи файла AssemblyInfo.cs или .vb.

Пример

<Target Name=»BuildNumberOverrideTarget»>

<Message Importance=»High» Text=»$(BuildNumber)» />

<ConvertTFSBuildNumberToSolutionBuildNumber

MajorAndMinorVersion=»l.0″

TFSBuildNumber=»$(BuildNumber)»

TFSLastBuildNumber=»$(LastBuildNumber)»>

<Output TaskParameter=»SolutionBuildNumber» PropertyName=»SolutionBuildNumber» />

<Output TaskParameter=»TFSBuildNumber» PropertyName=»BuildNumber» /> </ConvertTFSBuildNumberToSolutioriBuildNumber> <Message Importance=»High» Text=»$(SolutionBuildNumber)» /> <Message Importance=»High» Text=»$(BuildNumber)» /> </Target>

<Target Name=»BeforeCompile»>

<Message Importance=»High» Text=»$(SolutionBuildNumber)» /> <CreateItem Include=»$(SolutionRoot)\**\AssemblyInfo.cs»>

<Output TaskParameter=»Include» ItemName=»AssemblyInfoFiles»/> </CreateItem> <CreateItem Include=»$(SolutionRoot)\**\AssemblyInfo.vb»>

<Output TaskParameter=»Include» ItemName=»AssemblyInfoFiles»/> </CreateItem> <RewriteFileVersions

AssemblyInfoFiles=»@(AssemblylnfoFiles)»

AssemblyVersionNumber=»$(SolutionBuildNumber)»

AssemblyFileVersionNumber=»$(SolutionBuildNumber)»

AssemblyInformationalVersionNumber=»$(SolutionBuildNumber)» /> </Target>

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

Еще один метод изменения версии сборки предлагается в сообщении блога Аарона Холберга (Aaron Halberg) «Team Build and the Assemblylnfo Task» (Team Build и задача Assemblylnfo) по адресу

http://blogs.msdn.com/aaronhallberg/archive/2007/06/08/team-build-and-the-assemblyinfo-task.aspx.

Задаче Assemblylnfo, которая упоминается в указанном выше сообщении блога, посвящена новая страничка на GotDotNet. Ее можно найти по адресу http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=5C 455590-332С-433В-А648-Е368В9515580.

Подробнее о настройке Team Foundation Build рассказывается в статье «Customizing Team Foundation Build»по адресу http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx.

Как настроить отображение рабочего пространства для получения и сборки части дерева исходного кода

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

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

Чтобы сокрыть файлы и папки

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

2. Добавьте в него соответствующие записи для сокрытия.

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

Файл WorkspaceMapping.xml file выглядит следующим образом:

<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/library/ms181378(VS.80).aspx.

Более подробно о том, как заставить Team Build игнорировать папки, рассказывает статья «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 не поддерживает сборку решений, объединяющих несколько групповых проектов. Осуществить сборку таких решений можно, соответствующим образом настраивая файл TFSBuild.proj. Тогда при сборке необходимый код других проектов будет изыматься прямо из системы контроля версий.

Чтобы выполнить сборку проекта, имеющего зависимости от другого группового проекта, необходимо поместить исходный код или сборки того проекта в рабочее пространство на вашем сервере сборки. Для этого редактируйте файл TFSBuild.proj. Добавьте в него сборку или ссылку на решение и переопределите событие BeforeGet (Перед получением) для получения сборок или исходных файлов из всех групповых проектов, от которых зависит ваш проект.

Чтобы выполнить сборку проекта, который зависит от другого группового проекта

1. В Source Control Explorer извлеките для редактирования сценарий TFSBuild.proj.

2. Под секцией PropertyGroup (Группа свойств) добавьте следующие настройки конфигурации:

<!— должны находиться под PropertyGroup —>

<TfCommand>$(TeamBuildRefPath)\..\tf.exe</TfCommand>

<SkipInitializeWorkspace>true</SkipInitializeWorkspace>

SkipInitializeWorkSpace позволяет пропустить вызов задач по умолчанию для уничтожения и воссоздания рабочего пространства на компьютере сборки. Это новое свойство используется в специальной цели BeforeGet (смотрите ниже).

3. Добавьте следующие настройки конфигурации в записи ItemGroup, которые отвечают за отображение, как групповых проектов, так и решений. Убедитесь в правильности задания локальных путей для компьютера сборки. Одна локальная папка не может использоваться в нескольких отображениях. Это приведет к возникновению исключения MappingConflictException (Исключение «Конфликт отображений») при выполнении задачи CreateWorkspace (Создать рабочее пространство).

<ItemGroup>

<!— для каждого используемого решения добавляется по одной записи —> <SolutionToBuild Include=»$(SolutionRoot)\DependentApp\DependentApp.sln» /> <SolutionToBuild Include=»$(SolutionRoot)\YourApp\YourApp.sln» />

</ItemGroup>

<ItemGroup>

<!— для каждого используемого Team Project добавляется по одной записи —> <Map Include=»$/YourApp/YourApp»>

<LocalPath>$(SolutionRoot)\YourApp</LocalPath> </Map> <Map Include=»$/DependentApp/DependentApp»>

<LocalPath>$(SolutionRoot)\DependentApp</LocalPath> </Map> </ItemGroup>

4. Переопределите событие BeforeGet, чтобы рабочие пространства извлекались для каждого Team Project:

<Target Name=»BeforeGet»> <DeleteWorkspaceTask

TeamFoundationServerUrl=»$(TeamFoundationServerUrl)» Name=»$(WorkspaceName)» /> <Exec

WorkingDirectory=»$(SolutionRoot)»

Command=»&quot;$(TfCommand)&quot; workspace /new $(WorkSpaceName) /server:$(TeamFoundationServerUrl)»/>

<Exec

WorkingDirectory=»$(SolutionRoot)»

Command=»&quot;$(TfCommand)&quot; workfold /unmap /workspace:$(WorkSpaceName) &quot;$(SolutionRoot)&quot;»/> <Exec

WorkingDirectory=»$(SolutionRoot)»

Command=»&quot;$(TfCommand)&quot; workfold /map /workspace:$(WorkSpaceName) /server:$(TeamFoundationServerUrl) &quot;%(Map.Identity)&quot; &quot;%(Map.LocalPath)&quot;»/> </Target>

5. Зарегистрируйте изменения сценария в системе контроля версий и выполните сборку.

Примечание: В TFS 2008, для типов сценариев сборки больше нет ограничений на извлечение файлов из других групповых проектов. Можно просто редактировать отображения рабочих пространств с помощью диалогового окна Build Definition Editor (Редактор описания сборки) и отображать необходимые файлы.

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

Более подробную информацию можно найти в сообщении блога Маниша Агарвала (Manish Agarwal) «Working with multiple team projects in Team Build» (http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx).

Как изменить конфигурацию сборки (выпускаемая версия/отладочная версия)

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

Чтобы изменить конфигурацию сборки

1. Откройте Source Control Explorer.

2. В Source Control Explorer разверните папку своего группового проекта.

3. Разверните папку TeamBuildTypes.

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

5. Извлеките файл TFSBuild.proj из системы контроля версий. Возможно, сначала понадобится выполнить операцию Get Latest Version для папки.

6. Чтобы открыть TFSBuild.Proj, щелкните его двойным щелчком мыши в Source Control Explorer.

7. В теге <ConfigurationToBuild> измените конфигурацию сборки.

8. Сохраните TFSBuild.proj и верните его в систему контроля версий.

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

Подробнее о настройке Team Foundation Build рассказывается в статье

«Customizing Team Foundation Build» по адресу http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx.

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

• Как установить сервер сборки

Как определить, есть ли необходимость в нескольких серверах сборки Как установить сервер сборки

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

Чтобы установить сервер сборки

1. Установите Visual Studio.

Если необходимо гарантированно установить все инструменты, необходимые для любого сценария сборки, установите весь Team Suite.

Если требуется выполнять Team Build, но нет необходимости выполнять различные варианты тестирования, установите Visual Studio Team Developer Edition.

Если предполагается выполнять автоматизированные тесты как часть процесса сборки, установите Visual Studio Team Test Edition.

2. В каталоге на DVD-диске Team Foundation Server откройте папку \build.

3. Запустите мастер установки.

Учетная запись, используемая для запуска сервера сборки:

Должна обладать правом доступа Log On Locally (Локальный вход в систему) на компьютерах TFS.

Не должна быть локальной учетной записью администратора на компьютерах TFS.

Должна быть помечена как Account is sensitive and cannot be delegated (Учетная запись является критически важной и не может быть делегирована) в Microsoft Active Directory® домена.

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

Team Foundation Server Installation Guide (Руководство по установке Team Foundation Server) можно скачать по адресу

http://www.microsoft.com/downloads/details.aspx?familyid=e54bf6ff-026b-43a4-ade4-a690388f310e&displaylang=en.

Как определить, есть ли необходимость в нескольких серверах сборки

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

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

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

Общее

• Как с помощью Team Build выполнять сборку и развертывание приложений ASP.NET

• Как с помощью Team Build выполнять сборку приложений на основе Microsoft® .NET 1.1

• Как с помощью Team Build выполнять сборку проектов создания пакетов установки и развертывания

• Как создать тип сценария сборки

• Как создать несколько типов сценариев сборки

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

• Как подписаться на получение уведомлений о сборке по электронной почте

• Как получать уведомления о сбое при выполнении сборки

• Как запустить сборку

• Как убедиться в том, что сборка была выполнена успешно

• Как просмотреть результат сборки

• Как изменить местоположение сервера сборки

• Как изменить место размещения результатов сборки

• Как определить, какие пакеты изменений являются частью сборки

• Как изменить заявленное качество сборки

Как с помощью Team Build выполнять сборку и развертывание приложений ASP.NET

Если требуется выполнить сборку решения, содержащего только Веб-приложения ASP.NET, важно правильно выбрать конфигурацию. Выбирая конфигурацию и платформу при создании типа сценария сборки, убедитесь, что выбрана платформа .NET и конфигурация (Configuration) Debug:

Чтобы выполнить сборку решения, содержащего только проекты Веб-приложений ASP.NET

1. Запустите New Team Build Type Creation Wizard (Мастер создания нового типа сценария сборки).

2. Задайте имя типа сценария сборки.

3. Выберите решение, содержащее только Веб-приложение ASP.NET.

4. Выберите соответствующую конфигурацию.

5. В выпадающем списке Platform (Платформа) выберите платформу .NET.

6. Задайте данные о месторасположении для типа сценария сборки.

7. Выберите тесты и правила анализа кода, которые будут применяться.

8. Сохраните тип сценария сборки, нажав Finish (Завершить).

При сборке решения, включающего и Веб-приложения ASP.NET, и другие .NET-проекты, необходимо выбрать тип платформы Mixed Platforms (Смешанные платформы).

Чтобы выполнить сборку решения, содержащего Веб-приложения ASP.NET и другие .NET-проекты

1. Запустите New Team Build Type Creation Wizard.

2. Задайте имя типа сценария сборки.

3. Выберите решение, содержащее только Веб-приложения ASP.NET и другие проекты.

4. Выберите соответствующую конфигурацию.

5. В выпадающем списке Platform выберите Mixed.

6. Задайте данные о месторасположении для типа сценария сборки.

7. Выберите тесты и правила анализа кода, которые будут применяться.

8. Сохраните тип сценария сборки, нажав Finish.

Местом публикации скомпилированных двоичных файлов будет каталог {BuildType}\{Configuration Name}\{Platform}\_PublishedWebsites

Team Build не поддерживает развертывания Веб-приложений на Internet Information Services (IIS). Существует два варианта того, как включить развертывание приложения на IIS в сценарий сборки: добавить специальный этап в тип сценария сборки или использовать Web Deployment Project (Проект развертывания Веб-приложения).

Если работа над групповым проектом только начинается, необходимо рассмотреть вариант Web Deployment Project, чтобы понять, возможно ли его использование в вашей разработке. Для уже существующих Веб-сайтов использование проектов развертывания Веб-приложений может нарушить процесс разработки приложения. Тогда необходимо рассмотреть использование специального этапа после сборки MSBuild. В обоих случаях учетная запись сервиса, под которой выполняется сборка, должна являться членом локальной группы администраторов, что позволяет ей создавать виртуальный каталог в IIS.

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

1. Скачайте библиотеку SDC Tasks Library с сайта Codeplex по адресу http://www.codeplex.com/sdctasks.

2. Извлеките из системы контроля версий тип сценария сборки, который собираетесь использовать для развертывания Веб-приложения.

3. Из zip-архива, который скачали, извлеките файл Microsoft.Sdc.Tasks.dll в папку, в которую вы поместили для редактирования тип сценария сборки.

4. Добавьте DLL в систему контроля версий и зарегистрируйте ее.

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

a. Добавьте элемент <PropertyGroup>, определяющий местоположение скомпилированных Веб-приложений:

<PropertyGroup>

<WebBinariesLocation>$(SolutionRoot)\..\Binaries\.NET\Release\_Publishe

dWebSites\MyWebSite</WebBinariesLocation>

</PropertyGroup>

b. Добавьте два элемента UsingTask (Используемая задача), которые добавляют ссылки на задачи CreateVirtualDirectory (Создать виртуальный каталог) и DeleteVirtualDirectory (Удалить виртуальный каталог):

<UsingTask

TaskName=»Microsoft.Sdc.Tasks.Web.WebSite.CreateVirtualDirectory»

AssemblyFile=»Microsoft.Sdc.Tasks.dll» />

<UsingTask

TaskName=»Microsoft.Sdc.Tasks.Web.WebSite.CreateVirtualDirectory»

AssemblyFile=»Microsoft.Sdc.Tasks.dll» />

c. Добавьте цель AfterCompile (После компиляции) для создания виртуального каталога и копирования файлов в него:

<Target Name=»AfterCompile»>

<MakeDir Directories=»C:\Deploy\MyWebsite» /> <CreateVirtualDirectory VirtualDirectoryName=»MyWebSite»

Path=»C:\Deploy\Website» />

<DeleteVirtualDirectory VirtualDirectoryName=»MyWebSite» /> <Exec Command=»xcopy /y /e $(WebBinariesLocation)

C:\Deploy\MyWebsite»/>

</Target>

6. Сохраните файл и передайте его в хранилище системы контроля версий.

Теперь при выполнении сборки будет создаваться Веб-приложение и виртуальный каталог, в который это Веб-приложение будет копироваться.

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

1. Скачайте и установите Visual Studio 2005 Web Deployment Projects на свой клиентский компьютер.

2. Скачайте и установите Visual Studio 2005 Web Deployment Projects на свой сервер сборки.

3. Откройте решение, содержащее Веб-прложение.

4. В меню Build (Сборка) выберите Add Web Deployment Project… (Добавить проект развертывания Веб-приложения)

5. Задайте имя и местоположение проекта развертывания.

6. В Solution Explorer правой кнопкой мыши щелкните Web Deployment Project и выберите Property Pages (Страницы свойств).

7. В диалоговом окне выберите значение Configuration, соответствующее тому, какую сборку должен выполнять Team Build (Debug или Release).

8. В разделе Deployment (Развертывание) установите флажок Create an IIS virtual directory for the output folder (Создать виртуальный каталог IIS для выходной папки) и задайте имя виртуального каталога.

9. Щелкните OK.

10. Зарегистрируйте изменения в системе контроля версий.

При выполнении сборки, содержащей это решение, будет создано Веб-приложение и виртуальный каталог в каталоге, в котором выполняется сборка Веб-приложения. Это будет {Каталог сборки}\{Имя группового проекта}\{Тип сценария сборки}\Втапе5\{Имя конфигурации}\{Платформа}\_РиЫ15Иес^ШеЬ511е\{Имя проекта развертывания Веб-приложения.

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

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

Подробнее о сборке приложений ASP.NET с помощью Team Build рассказывает статья «TN_1600: Building ASP.NET projects with Team Build» (TN_1600: сборка проектов ASP.NET с помощью Team Build), которую можно найти по адресу http://msdn2.microsoft.com/en-us/teamsystem/aa718894.aspx.

Более подробную информацию об использовании проектов Web Deployment Project можно найти в статье «TN_1601: Team Build and Web Deployment Projects» по адресу http://msdn2.microsoft.com/en-us/teamsystem/aa718895.aspx.

Больше информации о сборке проектов Web Deployment Project предлагается в статье «Visual Studio 2005 Web Deployment Projects» по адресу http://msdn2.microsoft.com/en-us/asp.net/aa336619.aspx.

Как с помощью Team Build выполнять сборку приложений на основе Microsoft® .NET 1.1

MSBuild не поддерживает .NET 1.1, поэтому такой поддержки нет и в Team Build. Компания Microsoft опубликовала на сайте CodePlex проект под названием MSBuild Extras (MSBee), который поддерживает сборку приложений на основе .NET 1.1.

Чтобы выполнять сборку приложений .NET 1.1, необходимо обновить файл проекта до .NET 2.0. Также придется отредактировать файл типа сценария сборки, чтобы при сборке использовались инструменты .NET 1.1, а не инструменты .NET 2.0.

Чтобы выполнять сборку приложений .NET 1.1 с использованием Team Build 2005

1. Обновите свои решения .NET 1.1 до .NET 2.0. Сделать это можно, открыв решение в Visual Studio 2005 и выполнив Conversion Wizard (Мастер преобразования), или выполнив команду devenv [projectname] /upgrade.

2. Убедитесь, что на вашем сервере сборки установлен .NET 1.1 Software Development Kit (SDK).

3. Скачайте и установите MSBuild Extras (http://www.codeplex.com/MSBee).

4. Скачайте BuildingFxllinTB.targets с сайта http://blogs.msdn.com/gautamg/attachment/578915.ashx.

5. Извлеките для редактирования из системы контроля версий тип сценария сборки, по которому будет выполняться сборка проекта .NET 1.1.

6. Скопируйте BuildingFxllinTB.targets в каталог, содержащий тип сценария сборки, и зарегистрируйте файл в системе контроля версий.

7. Редактируйте файл TFSBuild.proj:

a. Импортируйте файл BuildingFxllinTB.targets:

<Import Project=»$(MSBuildProjectDirectory)\BuildingFxllinTB.targets» />

b. Добавьте свойство, определяющее цели CSharp:

<PropertyGroup>

<AdditionalPropertiesForBuildTarget>

CustomAfterMicrosoftCommoriTargets=$(ProgramFiles) \MSBuild\MSBee\MSBuild

Extras.Fxll.CSharp.targets

</AdditionalPropertiesForBuildTarget>

</PropertyGroup>

8. Зарегистрируйте файл TFSBuild.proj в системе контроля версий.

Примечание: В TFS 2008 в файле TFSBuild.proj надо просто добавить следующий элемент Properties в элемент SolutionToBuild.

<SolutionToBuild Include=»$(BuildProjectFolderPath)/path/MySolution.sln»>

<Properties> CustorrAfterMicrosoftCommoriTargets=$(ProgramFiles) \MSBuild\MSBee\MSBuildExtras.Fxl 1.CSharp.targets

</Properties> </SolutionToBuild>

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

Подробнее о MSBuild Extras расскажет статья «MSBuild Extras — Toolkit for .NET 1.1 «MSBee”» (MSBuild Extras — комплект инструментов для .NET 1.1 «MSBee”) по адресу http://www.codeplex.com/MSBee.

Больше информации об использовании MSBuild Extras для сборки приложений .NET 1.1 можно найти в статье «Building .NET 1.1 application using Team Build» (Сборка приложения .NET 1.1 с использованием Team Build) по адресу http://blogs.msdn.com/gautamg/archive/2006/04/19/578915.aspx.

Как с помощью Team Build выполнять сборку проектов создания пакетов установки и развертывания

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

1. Простестируйте сборку.

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

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

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

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

2. Щелкните Properties.

3. Щелкните Configuration Manager…

4. Выберите необходимые конфигурацию(-и) сборки; например, Debug, Release.

5. Установите флажок Build для проекта создания пакета установки.

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

1. Откройте папку решения для проекта создания пакета установки приложения.

2. Откройте файл .vdproj в любом другом редакторе (не в Visual Studio).

3. Извлеките файл .vdproj из системы контроля версий для редактирования.

4. Найдите следующие записи: SccLocalPath (Локальный путь в системе контроля версий), SccAuxPath (Вспомогательный путь в системе контроля версий), OutputFileName (Имя выходного файла) и SourcePath (Путь к исходному файлу).

5. Убедитесь, что каждый из этих путей является относительным, а не абсолютным. (Относительные пути должны задаваться по умолчанию при создании проекта.) Абсолютные пути начинаются с имени диска. Относительные пути начинаются с двойной прямой косой черты (‘\\’) или вообще не имеют никаких дополнительных символов.

6. Все обнаруженные абсолютные пути замените относительными. Не меняйте константные выражения. Они будут раскрыты программой установки позднее; например:

«OutputFileName» = «8:c:\\temp\\SetupProject.msi» должен быть заменен «OutputFileName» = «8:debug\\SetupProject.msi»

Подсказка: Относительные пути разрешаются относительно папки проекта.

Подсказка: При создании путей должна использоваться двойная прямая косая черта ( ‘\\’ ), потому что потом она декодируется в одиночную прямую косую черту ( ‘\’ ).

7. Если были внесены какие-либо изменения, зарегистрируйте их в системе контроля версий.

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

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

2. Извлеките сценарий сборки из системы контроля версий для редактирования:

a. Файл типа сценария сборки TFSBuild.proj находится в системе контроля версий в каталоге группового проекта в подпапке папки TeamBuildTypes.

b. Возможно, для папки сначала понадобится выполнить операцию Get Latest Version.

3. Чтобы открыть TFSBuild.Proj, щелкните его двойным щелчком мыши в Source Control Explorer.

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

4. Добавьте следующий код в конец файла между последним тегом </ItemGroup> и последним тегом </Project>:

<Target Name=»AfterCompile»>

<Exec Command=»&quot;C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv&quot; &quot;C:\Documents and Settings\darren\My Documents\Visual Studio

2005\Projects\HelloWorldTest\HelloWorldTestInstaller\HelloWorldTestInstaller.vd proj&quot; /Build &quot;Debug&quot;»/>

<Copy SourceFiles=»C:\Documents and Settings\darren\My Documents\Visual Studio

2005\Projects\HelloWorldTest\HelloWorldTestInstaller\Debug\HelloWorldTestInstal ler.msi» DestinationFolder=»$(OutDir)» />

<Copy SourceFiles=»C:\Documents and Settings\darren\My Documents\Visual Studio

2005\Projects\HelloWorldTest\HelloWorldTestInstaller\Debug\setup.exe» DestinationFolder=»$(OutDir)» /> </Target>

5. Убедитесь в правильности и соответствии серверу сборки путей во вставленном фрагменте кода.

Подсказка: Для тестирования пути, указанного в теге <exec command>, используется командная строка. При тестировании в командной строке каждый &quot; заменяется кавычкой, например:

«C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv» «C:\Documents and Settings\darren\My Documents\Visual Studio

2005\Projects\HelloWorldTest\HelloWorldTestInstaller\HelloWorldTestInstaller.vd proj» /Build «Debug»

Подсказка: Используйте командную строку также и для тестирования путей SourceFiles.

5. Протестируйте изменения, внесенные в сборку.

1. В Team Explorer правой кнопкой мыши щелкните тип сценария сборки и затем щелкните Build Team Project.

2. Посмотрите в отчете о результатах сборки, была ли сборка успешной или дала сбой.

3. Если сборка дала сбой, щелкните ссылку на протокол сборки. Как правило, причинами сбоя сборки являются:

a. Неверный путь команды exec.

b. Неверно заданы права доступа, что препятствует копированию выходных файлов в каталог сборки. Убедитесь, что учетная запись пользователя tfsservice имеет право копировать файлы из папки двоичных файлов в папку сборки. Папка двоичных файлов — это папка, в которую помещается файл msi после сборки решения. Папка сборки определена в файле в теге <BuildDirectoryPath> (Путь к каталогу сборки).

c. Неверно заданы права доступа, что препятствует выполнению сборки проекта пакета установки приложения. Убедитесь, что учетная запись пользователя tfsserver обладает правом чтения файла .vdproj и исходных файлов проекта создания пакета установки приложения, а также приложения, с которым ассоциирован проект установки. Также учетная запись пользователя tfsserver должна иметь право записи двоичных файлов в выходной каталог; например, Debug или Release.

d. Неверная конфигурация сборки. Убедитесь, что заданная в теге exec command конфигурация сборки существует для вашего проекта. Например, проект может иметь конфигурацию «Debug | Any CPU», но не иметь «Debug». Это можно проверить, посмотрев свойства решения в Solution Explorer.

4. Если протокол сборки не дает достаточной информации, создайте выходной файл для exec command и просмотрите этот протокол для получения более подробных данных. Например:

<Ехес Command=»&quot;C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv&quot; Squot;C:\Documents and Settings\darren\My DocumentsWisual Studio

2005\Projects\HelloWorldTest\HelloWorldTestInstaller\HelloWorldTestInstaller.vd proj&quot; /Build Squot;Debug&quot; > c:\temp\output.txt»/>

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

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

Как создать тип сценария сборки

Создать новый сценарий сборки можно из папки Team Builds в Team Explorer.

Чтобы создать сценарий сборки

1. Откройте Team Explorer.

2. Разверните групповой проект, для которого хотите создать сценарий сборки.

3. Щелкните правой кнопкой мыши папку Team Builds в дереве каталогов.

4. Выберите New Team Build Type…

5. Задайте имя нового типа сценария сборки и щелкните Next.

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

7. Выберите конфигурацию сборки (например, выпускаемая версия или отладочная версия) и щелкните Next.

8. Задайте имя сервера сборки, например, TFSRTM.

9. Задайте локальный каталог сборки на вашем сервере сборки, например, c:\builds.

10. Задайте место публикации результатов сборки, например, \\TFSRTM\NightlyBuilds и затем щелкните Next.

11. Установите флажок Run tests (Выполнять тесты), выберите список тестов, которые хотите ассоциировать со сборкой, и затем щелкните Next.

12. Щелкните Finish, чтобы создать новый тип сценария сборки.

Как создать несколько типов сценариев сборки

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

Чтобы создать сценарий сборки

1. Откройте Team Explorer.

2. Разверните групповой проект, для которого хотите создать сборку.

3. Щелкните правой кнопкой мыши папку Team Builds в дереве каталогов.

4. Выберите New Team Build Type…

5. Задайте имя нового типа сценария сборки и щелкните Next.

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

7. Выберите конфигурацию сборки (например, выпускаемая версия или отладочная версия) и щелкните Next.

8. Задайте имя сервера сборки, например, TFSRTM.

9. Задайте локальный каталог сборки на вашем сервере сборки, например, c:\builds.

10. Задайте место публикации результатов сборки, например, \\TFSRTM\NightlyBuilds и затем щелкните Next.

11. Установите флажок Run tests, выберите список тестов, которые хотите ассоциировать со сборкой, и затем щелкните Next.

12. Щелкните Finish, чтобы создать новый тип сценария сборки.

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

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

Чтобы выполнить сборку проекта, использующего сборки из другого группового проекта

1. В Source Control Explorer извлеките для редактирования сценарий TFSBuild.proj.

2. Под секцией PropertyGroup добавьте следующие настройки конфигурации:

<!— должны быть добавлены под PropertyGroup —>

<TfCommand>$(TeamBuildRefPath)\..\tf.exe</TfCommand> <SkipInitializeWorkspace>true</SkipInitializeWorkspace>

SkipInitializeWorkSpace позволяет пропустить вызов задач по умолчанию для уничтожения и воссоздания рабочего пространства на компьютере сборки. Это новое свойство используется в специальной цели BeforeGet (смотрите ниже).

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

<ItemGroup>

<!— для каждого используемого решения добавляется по одной записи —> <SolutionToBuild Include=»$(SolutionRoot)\DependentApp\DependentApp.sln» /> <SolutionToBuild Include=»$(SolutionRoot)\YourApp\YourApp.sln» />

</ItemGroup>

<ItemGroup>

<!— для каждого используемого Team Project добавляется по одной записи —> <Map Include=»$/YourApp/YourApp»>

<LocalPath>$(SolutionRoot)\YourApp</LocalPath> </Map> <Map Include=»$/DependentApp/DependentApp»>

<LocalPath>$(SolutionRoot)\DependentApp</LocalPath> </Map> </ItemGroup>

4. Переопределите событие BeforeGet, чтобы рабочие пространства извлекались для каждого Team Project:

<Target Name=»BeforeGet»> <DeleteWorkspaceTask

TeamFoundationServerUrl=»$(TeamFoundationServerUrl)» Name=»$(WorkspaceName)» /> <Exec

WorkingDirectory=»$(SolutionRoot)»

Command=»&quot;$(TfCommand)&quot; workspace /new $(WorkSpaceName) /server:$(TeamFoundationServerUrl)»/> <Exec

WorkingDirectory=»$(SolutionRoot)»

Command=»&quot;$(TfCommand)&quot; workfold /unmap /workspace:$(WorkSpaceName) &quot;$(SolutionRoot)&quot;»/> <Exec

WorkingDirectory=»$(SolutionRoot)»

Command=»&quot;$(TfCommand)&quot; workfold /map /workspace:$(WorkSpaceName) /server:$(TeamFoundationServerUrl) &quot;%(Map.Identity)&quot; &quot;%(Map.LocalPath)&quot;»/> </Target>

5. Зарегистрируйте изменения сценария в системе контроля версий и выполните сборку.

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

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

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

Как подписаться на получение уведомлений о сборке по электронной почте

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

Чтобы настроить получение уведомлений о выполнении сборки по электронной почте

1. Щелкните правой кнопкой мыши соответствующий групповой проект в Team Explorer.

2. Выберите Project Alerts.

3. Выберите все варианты уведомлений, которые хотите получать, и введите адрес электронной почты.

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

Подробнее об уведомлениях проекта рассказывается в статье «Setting Alerts» (Настройка уведомлений) по адресу http://msdn2.microsoft.com/en-us/library/msl81334(VS.80).aspx.

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

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

Чтобы создать уведомление проекта, сообщающее о сбое сборки

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

2. Подпишитесь на событие BuildCompletionEvent. С помощью инструмента BisSubscribe.exe подпишитесь на событие BuildCompletionEvent и задайте фильтр, определяющий, что вы хотите получать уведомления по электронной почте только при сбое сборки. Используйте для этого следующий синтаксис командной строки:

bissubscribe /eventType BuildCompletionEvent /address myemail@domain.com /deliveryType EmailPlaintext /server tfsserverl /filter «TeamProject = ‘MyTeamProject’ AND CompletionStatus=’Failed’“

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

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

Более подробную информацию о фильтрах для событий о завершении сборки можно найти в статье «How to Filter the Build Completion Event» (Применения фильтра к событию завершения сборки) по адресу

http://blogs.msdn.com/ipricket/archive/2006/09/05/how-to-filter-the-build-completion-event.aspx.

Подробнее о фильтрах BuildCompletionEvent рассказывает статья «Useful BuildCompletionEvent Filters» (Полезные фильтры BuildCompletionEvent) по адресу http://blogs.msdn.com/ipricket/archive/2006/09/05/useful-buildcompletionevent-filters.aspx.

Как запустить сборку

Запустить тип сценария сборки можно из папки Team Builds в Team Explorer.

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

1. Откройте Team Explorer.

2. Разверните групповой проект, сборку которого хотите начать.

3. Разверните папку Team Builds в дереве каталогов.

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

5. Выберите Build Team Project.

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

Статус сборки можно проверить в окне Builds, которое доступно из Team Explorer.

Чтобы убедиться в успешном выполнении сборки

1. Откройте Team Explorer.

2. Разверните проект, для которого хотите посмотреть результаты.

3. Разверните папку Team Builds в дереве каталогов.

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

Как просмотреть результат сборки

Результат сборки можно просмотреть в окне Builds, которое доступно из Team Explorer.

Чтобы просмотреть результат сборки

1. Откройте Team Explorer.

2. Разверните групповой проект, для которого хотите увидеть результат сборки.

3. Разверните папку Team Builds в дереве каталогов.

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

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

6. Если хотите увидеть папку с результатом сборки, щелкните ссылку Build name (Имя сборки).

7. Если хотите увидеть протокол сборки, щелкните ссылку Log (Протокол).

Как изменить местоположение сервера сборки

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

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

1. Откройте Source Control Explorer.

2. В Source Control Explorer разверните папку своего группового проекта.

3. Разверните папку TeamBuildTypes.

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

5. Извлеките файл TFSBuild.proj из системы контроля версий. Возможно, сначала понадобится выполнить операцию Get Latest Version для папки.

6. Чтобы открыть TFSBuild.Proj, щелкните его двойным щелчком мыши в Source Control Explorer.

7. Измените тег <BuildMachine>, чтобы он указывал на другой сервер.

8. Сохраните TFSBuild.proj и верните его в систему контроля версий.

Примечание: В TFS 2008 тег <BuildMachine> уже не используется. Вместо этого в описании сборки задается агент сборки. Редактирование агентов сборки выполняется посредством опции Manage Build Agents (Управление агентами сборки), которую можно найти, щелкнув правой кнопкой мыши по узлу Builds в Team Explorer Build. Агент сборки можно задать при запуске новой сборки.

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

Подробнее о настройке Team Foundation Build рассказывается в статье

«Customizing Team Foundation Build» по адресу http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx.

Как изменить место размещения результатов сборки

Чтобы изменить место размещения результатов сборки для существующего Team Build, редактируйте тег <DropLocation> в файле TFSBuild.proj.

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

1. Откройте Source Control Explorer.

2. В Source Control Explorer разверните папку своего группового проекта.

3. Разверните папку TeamBuildTypes.

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

5. Извлеките файл TFSBuild.proj из системы контроля версий. Возможно, сначала понадобится выполнить операцию Get Latest Version для папки.

6. Чтобы открыть TFSBuild.Proj, щелкните его двойным щелчком мыши в Source Control Explorer.

7. Измените тег <DropLocation>, чтобы он указывал на новое местоположение.

8. Сохраните TFSBuild.proj и верните его в систему контроля версий.

Примечание: В TFS 2008 тег <DropLocation> уже не используется. Чтобы задать место публикации результатов сборки, щелкните правой кнопкой мыши описание соответствующей сборки под узлом Builds в Team Explorer, выберите Edit Build Definition, щелкните Build Defaults (Настройки сборки по умолчанию) и задайте место публикации.

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

Подробнее о настройке Team Foundation Build рассказывается в статье

«Customizing Team Foundation Build» по адресу http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx.

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

Увидеть, какие пакеты изменений ассоциированы с каждой сборкой, можно из окна Builds, которое доступно из Team Explorer.

Чтобы увидеть пакеты изменений, ассоциированные со сборкой

1. Откройте Team Explorer.

2. Разверните групповой проект, для которого хотите просмотреть пакеты изменений.

3. Разверните папку Team Builds в дереве каталогов.

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

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

6. Разверните элемент Associated changesets (Ассоциированные пакеты изменений).

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

Как изменить заявленное качество сборки

Качество сборки можно изменить из окна Builds, которое доступно из Team Explorer.

Чтобы изменить качество сборки

1. Откройте Team Explorer.

2. Разверните групповой проект, для которого хотите изменить качество сборки.

3. Разверните папку Team Builds в дереве каталогов.

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

5. В выпадающем списке Build Quality (Качество сборки), выберите сборку, для которой хотите задать качество сборки, и задайте значение качества сборки.

Проекты

• Как использовать стратегию с одиночным решением

• Как использовать стратегию с сегментированным решением

• Как использовать стратегию с несколькими решениями

Как использовать стратегию с одиночным решением

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

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

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

Как использовать стратегию с сегментированным решением

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

При работе с несколькими решениями все проекты должны иметь плоскую структуру. Типичный пример – приложение, включающее проект Microsoft Windows® Forms, проект ASP.NET, службу Windows и ряд библиотек классов, которые совместно используются некоторыми или всеми перечисленными проектами.

Для всех проектов может использоваться следующая плоская структура:

/Source

о /WinFormsProject

о /WebProject

о /WindowsServiceProject

о /ClassLibraryl

о /ClassLibrary2

о /ClassLibrary3

о Web.sln

о Service.sln

о All.sln

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

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

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

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

Как использовать стратегию с несколькими решениями

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

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

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

Создание и отображение отчетов

• Как просмотреть информацию о качестве сборки

• Как увидеть все регистрации изменений для сборки

• Как просмотреть закрытые рабочие элементы или дефекты, ассоциированные со сборкой

• Как просмотреть рабочие элементы или дефекты, ассоциированные со сборкой

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

• Как отслеживать для сборки, какие тесты были пройдены, а какие нет

• Как увидеть статус сборки (результаты тестов верификации сборки)

Как просмотреть информацию о качестве сборки

Информацию о качестве сборки можно найти в окне Builds, которое доступно из Team Explorer.

Чтобы просмотреть информацию о качестве сборки

1. Откройте Team Explorer.

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

3. Разверните папку Team Builds в дереве каталогов.

4. Щелкните двойным щелчком тип сценария сборки и просмотрите качество сборки.

Если используется шаблон процесса Microsoft Solutions Framework (MSF) для CMMI® Process Improvement (MSF CMMI), информацию о качестве сборки, а также дополнительные данные по результатам тестов, покрытию кода тестами и степени изменения кода, можно увидеть в отчете Builds.

Чтобы просмотреть информацию о качестве сборки в MSF CMMI

1. В Team Explorer разверните узел вашего группового проекта.

2. Щелкните правой кнопкой мыши Reports и затем щелкните Show Report Site.

3. На сайте отчетов выберите отчет Builds.

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

Регистрации изменений, ассоциированные с каждой сборкой, можно увидеть в окне Builds, которое доступно из Team Explorer.

Чтобы увидеть регистрации изменений, ассоциированные со сборкой

1. Откройте Team Explorer.

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

3. Разверните папку Team Builds в дереве каталогов.

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

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

6. Разверните элемент Associated changesets, чтобы увидеть все регистрации изменений, ассоциированные со сборкой.

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

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

Рабочие элементы и дефекты, которые были закрыты для каждой сборки, можно увидеть в окне Builds, которое доступно из Team Explorer.

Чтобы просмотреть рабочие элементы, ассоциированные со сборкой

1. Откройте Team Explorer.

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

3. Разверните папку Team Builds в дереве каталогов.

4. Щелкните двойным щелчком тип сценария сборки, рабочие элементы которого хотите просмотреть.

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

6. Разверните элемент Associated work items.

Как просмотреть рабочие элементы или дефекты, ассоциированные со сборкой

Если используется шаблон процесса MSF CMMI, открытые, решенные и закрытые рабочие элементы за указанный период времени можно увидеть в отчете Open Issues and Blocked Work Items Trend (Открытые проблемы и блокированные рабочие элементы). Однако поскольку отчет представляет информацию, сортированную по датам, а не по сборкам, результаты необходимо пересортировать по сборкам, соответственно датам их создания.

Чтобы просмотреть открытые рабочие элементы или дефекты для конкретной сборки

1. В Team Explorer разверните узел своего группового проекта.

2. Щелкните правой кнопкой мыши Reports и затем щелкните Show Report Site.

3. На сайте отчетов выберите отчет Open Issues and Blocked Work Items Trend.

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

Отслеживать прогресс в выполнении проекта и темпы выполнения рабочих элементов от сборки к сборке можно с помощью отчета Velocity. Этот отчет доступен как в шаблоне проекта MSF CMMI, так и в шаблоне MSF для Agile Software Development (MSF Agile).

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

1. В Team Explorer разверните узел своего группового проекта.

2. Щелкните правой кнопкой мыши Reports и затем щелкните Show Report Site.

3. На сайте отчетов выберите отчет Velocity.

Как отслеживать для сборки, какие тесты были пройдены, а какие нет

Отслеживать количество пройденных и непройденных сценариев тестирования за указанный период времени можно с помощью отчета Quality Indicators. Этот отчет представляет информацию, сортированную по дате, а не по сборке, т.е. необходимо пересортировать результаты по сборкам, соответственно датам их создания. Этот отчет доступен как в MSF CMMI, так и в MSF Agile.

Чтобы отследить для сборки пройденные и непройденные сценарии тестирования

1. В Team Explorer разверните узел своего группового проекта.

2. Щелкните правой кнопкой мыши Reports и затем щелкните Show Report Site.

3. На сайте отчетов выберите отчет Quality Indicators.

Как увидеть статус сборки (результаты тестов верификации сборки)

Если используется шаблон процесса MSF CMMI, результаты тестов верификации сборки можно найти в отчете Builds.

Чтобы просмотреть статус сборки

1. В Team Explorer разверните узел своего группового проекта.

2. Щелкните правой кнопкой мыши Reports и затем щелкните Show Report Site.

3. На сайте отчетов выберите отчет Builds.

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

• Как настроить автоматический запуск сборки каждую ночь

• Как выбрать для проекта частоту выполнения сборки и тип сборки

Как настроить автоматический запуск сборки каждую ночь

Функция Team Build в TFS не поддерживает создание плановых сборок из пользовательского интерфейса. Поэтому для запуска сборок в заданное время используется планировщик задач Microsoft Windows Task Scheduler и командный файл TFSBuild.

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

1. Создаем строку команды запуска TFSBuild:

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

2. Помещаем строку команды запуска в командный файл.

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

Более подробная информация представлена в разделе «Как: настроить плановую сборку в Visual Studio Team Foundation Server».

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

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

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

Как выбрать для проекта частоту выполнения сборки и тип сборки

Выбор частоты выполнения сборок — одно из самых важных решений при создании плановой сборки.

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

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

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

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

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

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

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

• Как создать приемочный тест «Здравствуй, мир»

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

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

• Как реализовать сбой сборки при непрохождении тестов

Как создать приемочный тест «Здравствуй, мир»

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

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

Чтобы создать приемочный тест

1. В меню Test (Тест) щелкните New Test… (Новый тест)

2. Щелкните Unit Test (Модульный тест) и затем щелкните OK.

3. Введите имя своего проекта тестирования и затем щелкните Create (Создать).

4. Откомпилируйте новый проект.

5. Зарегистрируйте проект в системе контроля версий.

6. В Visual Studio при открытом решении модульного теста в меню Test щелкните Create New Test List… (Создать новый список тестов)

7. В диалоговом окне Create New Test List задайте имя списка тестов и щелкните OK.

8. В Test Manager щелкните узел All Loaded Tests (Все загруженные тесты).

9. Методом drag-and-drop перенесите тесты из доступных тестов в узел вашего списка тестов.

10. Зарегистрируйте в системе контроля версий измененный VSMDI-файл проекта модульного теста.

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

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

Подробнее об автоматическом выполнении Тестов верификации сборки (Build Verification Tests) рассказывается в статье «How to: Configure and Run Build Verification Tests (BVTs)» по адресу 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)», которую можно найти по адресу http://blogs.msdn.com/buckh/archive/2006/11/04/how-to-run-tests-without-test-metadata-files-and-test-lists-vsmdi-files.aspx.

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

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

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

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

2. В меню Test щелкните Create New Test List

3. С помощью Test Manager сгруппируйте тесты в новый Test List, перенося их методом drag-and-drop из Test View в Test List.

4. Создайте новый тип сценария сборки.

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

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

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

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

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

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

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

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

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

Подробнее об автоматическом выполнении Тестов верификации сборки (Build Verification Tests) рассказывается в статье «How to: Configure and Run Build Verification Tests (BVTs)» по адресу 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)», которую можно найти по адресу http://blogs.msdn.com/buckh/archive/2006/11/04/how-to-run-tests-without-test-metadata-files-and-test-lists-vsmdi-files.aspx.

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

Включить анализ кода в сценарий сборки можно или при создании нового типа сценария сборки, установив соответствующий флажок в New Team Build Type Creation Wizard, или изменяя файл 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.

Как реализовать сбой сборки при непрохождении тестов

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

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

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

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. Примечание: Обычно применяется две задачи инструмента тестирования. Чтобы изменить поведение сборок только на сервере сборки, меняется задача серверной сборки. Задача сборки на рабочей станции используется при сборке на рабочем столе разработчика

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

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

Предлагаемое выше решение легко реализовать, но нет гарантии, что оно будет применимо в будущих версиях 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.

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

Более подробную информацию о том, как настроить сборку, чтобы при непрохождении теста создавался рабочий элемент, можно найти в статье «Create Workitems for Test Failures in TeamBuild» по адресу http://blogs.msdn.com/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

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

<< Назад

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