Программирование на С#

:

Командная разработка с использованием Visual Studio Team Foundation Server
[+]
Опубликован: 25.03.2010 | Уровень: специалист | Доступ: платный
Дополнительный материал 2:

Практические рекомендации
A
|
версия для печати
< Дополнительный материал 1 || Дополнительный материал 2: 1234567891011 || Дополнительный материал 3 >
Ключевые слова: администрирование, интеграция, overview, walkthrough, disallow, версия сборки, файл, сборка, тег, относительный путь, запуск, сервер, агент, место, trending, velocity, функция, планировщик задач, task scheduler, утилита, группа, список, unit testing, test management, load testing, анализ, сценарий, analysis tool, team, build, управление проектом, удобство сопровождения, интероперабельность, code analysis, unsubscribe, content management, RDL, shared data, Report Designer, cube, pivot table, pivot, data item, доступ, ветвление, отладка, блокировка, безопасность, visual foxpro, управляющий сценарий, command file, version control, checkout, снятие блокировки, приветственное сообщение, монопольная блокировка, conflict, test policy, server software, event service, overwrite, writable, edit command, configuration file, рабочий цикл, ISA Server, cache performance, VSS, component software, RCS, CVS, SVN, зависимые проекты, security team

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

В этом разделе

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

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

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

  • Как с помощью политик возврата повысить качество возвращаемых изменений.
  • Как связать рабочие элементы со сборкой при помощи политики возврата изменений.

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

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

Настройка

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

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

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

Общие вопросы

  • Как с помощью 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 полными административными правами.

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

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

Для удаления сборок используется инструмент командной строки TFSBuild. Задайте адрес сервера TFS, имя командного проекта и имя сборки, например: TfsBuild delete http://mytfsserver:8080 myproject build20070606.4

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

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

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

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

Удаление типа сборки

  1. Откройте Source Control Explorer.
  2. Разверните папку своего командного проекта.
  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 необходимо удалить из системы управления исходным кодом отдельно.

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

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

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

Связывание рабочего элемента со сборкой

  1. Внесите в код изменения, которые хотите включить в сборку и связать с рабочим элементом.
  2. Верните ожидающие изменения в систему управления исходным кодом.
  3. В диалоговом окне Check In щелкните Work Items.
  4. Выберите рабочие элементы, которые хотите связать с этим возвратом. Все изменения, внесенные с момента последней успешной сборки, будут связаны со следующей сборкой. После очередной сборки Team Build внесет этот набор изменений в список наборов, связанных со сборкой, и свяжет выбранный рабочий элемент с этим набором изменений.

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

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

  • Как с помощью политик возврата повысить качество возвращаемых изменений.
  • Как связать рабочие элементы со сборкой при помощи политики возврата изменений.

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

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

Включение политики анализа кода при возврате изменений

  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/library/ms181281(VS.80).aspx.
  • Чтобы посмотреть пример кода, который запрещает возврат правок с определенными вариантами кодирования, читайте статью "Checkin Policy to Disallow Certain Patterns" по адресу http://blogs.msdn.com/jmanning/ar-chive/2006/02/02/523125.aspx.
  • Чтобы посмотреть пример кода, который обязывает вводить комментарии при возврате после правки, читайте статью "Sample Checkin Policy: Make Sure the Comment Isn't Empty" по адресу http://blogs.msdn.com/ jmanning/archive/2006/01/21/515858.aspx.
  • Чтобы узнать, как зарегистрировать новую политику возврата после правки, читайте статью "I've Made a New Check-In Policy! How Do I Add It?" по адресу http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx.

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

Политики возврата изменений позволяют обеспечить связывание каждого возврата изменений с рабочим элементом. Чтобы связать рабочие элементы с возвратом изменений, разработчики используют диалоговое окно 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/ms181281(VS.80).aspx.

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

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

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

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

Создание решения непрерывной интеграции

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

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

    <add key="1" value="TeamServer=http://TFSRTM:8080;
  TeamProjectName=Advent ureWorks;BuildType=Test Build"/>

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

    Bissubscribe /eventType CheckinEvent /address 
  http://TFSRTM:8080/ci/no-tify.asmx /deliveryType Soap /domain http://TFSRTM:8080
  5. Протестируйте непрерывную интеграцию Протестируйте сборку по завершении возврата. Подождите несколько минут, чтобы сборка завершилась, и затем проверьте на странице сборок, успешно ли она была завершена.
  6. Настройте рассылку уведомлений по электронной почте Они проинформируют заинтересованные стороны о завершении сборки. При помощи контекстного меню командного проекта откройте диалоговое окно Project Alerts и установите флажок уведомления Abuild completes.

Подробнее - в разделе "Как настроить непрерывную интеграцию в Visual Studio Team Foundation Server " этого курса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка

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

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

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

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

Настройка номера сборки в файле сборке и в интерфейсе Team Build
  1. Переопределите $(BuildNumber) в цели BuildNumberOverride.

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

    Пример

    <Target Name="BuildNumberOverrideTarget">
<Message Importance="High" Text="$(BuildNumber)" /> 
<ConvertTFSBuildNumberToSolutionBuildNumber
 MajorAndMinorVersion="1.0" 
 TFSBuildNumber="$(BuildNumber)" 
 TFSLastBuildNumber="$(LastBuildNumber)">
   <Output TaskParameter="SolutionBuildNumber" 
       PropertyName="SolutionBui ldNumber" />
   <Output TaskParameter="TFSBuildNumber"  
       PropertyName="BuildNumber" />    
 </ConvertTFSBuildNumberToSolutionBuildNumber> 
 <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="@(AssemblyInfoFiles)"   
  AssemblyVersionNumber="$(SolutionBuildNumber)"  
  AssemblyFileVersionNumber="$(SolutionBuildNumber)"  
  AssemblyInformationalVersionNumber="$(SolutionBuildNumber)" /> 
</Target>

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

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

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

Например, по умолчанию новый проект сопоставляется с папкой $/Team-Project. Если все файлы исходных кодов находятся в папке $/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 более не хранятся.

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

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

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, чтобы рабочие области извлекались для каждого командного проекта:
    <Target Name="BeforeGet">
  <DeleteWorkspaceTask
   TeamFoundationServerUrl="$(TeamFoundationServerUrl)"  
   Name="$(WorkspaceName)" /> 
   <Exec WorkingDirectory="$(SolutionRoot)"
   Command=""$(TfCommand)"  workspace /new $(WorkSpaceName) /  
        server:$(TeamFoundationServerUrl)"/> <Exec
    WorkingDirectory="$(SolutionRoot)"
    Command=""$(TfCommand)"  workfold /unmap /workspace:$(WorkS paceName) 
    "$(SolutionRoot)""/> 
    <Exec  WorkingDirectory="$(SolutionRoot)"
    Command=""$(TfCommand)"  workfold /map /workspace:$(WorkSp aceName) /server:$(TeamFoundationServerUrl) "
  %(Map.Identity)" "%(Map.LocalPath)""/> 
</Target>
  5. Верните изменения сценария в систему управления исходным кодом и выполните сборку.

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

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

Как изменить конфигурацию сборки (release/debug)

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

Изменение конфигурации сборки

  1. Откройте Source Control Explorer.
  2. Разверните папку своего командного проекта.
  3. Разверните папку TeamBuildTypes.
  4. Выберите папку сценария сборки, для которого хотите включить анализ кода.
  5. Извлеките файл TFSBuild.proj из системы управления версиями. Возможно, сначала понадобится выполнить для папки операцию Get Latest Version.
  6. Чтобы открыть TFSBuild.Proj, в окне Source Control Explorer щелкните его дважды.
  7. Измените конфигурацию сборки в теге <ConfigurationToBuild> .
  8. Сохраните TFSBuild.proj и верните его в систему управления версиями .

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

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

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

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

Сервер сборки устанавливается отдельно от 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 ;
  • не может быть делегирована в домене Microsoft Active Directory®.

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

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

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

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

Общие вопросы

  • Как с помощью Team Build выполнять сборку и развертывание приложений ASP.NET
  • Как с помощью Team Build выполнять сборку приложений на основе Microsoft® .NET 1.1.
  • Как с помощью Team Build выполнять сборку проектов пакетов установки и развертывания.
  • Как создать тип сборки.
  • Как создать несколько типов сборки.
  • Как создать сценарий сборки для проекта, в котором используются сборки из другого проекта.
  • Как подписаться на получение уведомлений о сборке по электронной почте.
  • Как получать уведомления о сбое при выполнении сборки.
  • Как запустить сборку.
  • Как убедиться, что сборка была выполнена успешно.
  • Как просмотреть результат сборки.
  • Как изменить расположение сервера сборки.
  • Как изменить место накопления результатов сборки.
  • Как определить, какие наборы изменений являются частью сборки.
  • Как изменить заявленное качество сборки.

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

Если требуется выполнить сборку решения, содержащего только веб-приложения ASP.NET, важно правильно выбрать конфигурацию. Создавая тип сборки, убедитесь, что выбрана платформа .NET и конфигурация 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.

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

  1. Запустите New Team Build Type Creation Wizard.
  2. Задайте имя типа сборки.
  3. Выберите решение, содержащее веб-приложения ASP.NET и другие проекты.
  4. Выберите соответствующую конфигурацию.
  5. В раскрывающемся списке Platform выберите вариант Mixed.
  6. Задайте расположение типа сборки.
  7. Выберите тесты и правила анализа кода.
  8. Сохраните тип сборки, щелкнув Finish.

Местом накопления скомпилированных двоичных файлов будет папка {Тип сборки}\{Название конфигурации}\{Платформа}\_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, чтобы файлы при сборке копировались в соответствующую папку, а затем сделайте эту папку виртуальной:
    • Добавьте элемент <PropertyGroup> , определяющий расположение скомпилированных веб-приложений:
      <PropertyGroup>
  <WebBinariesLocation>$(SolutionRoot)\..\Binaries\.NET\Release\_ PublishedWebSites\MyWebSite
  </WebBinariesLocation> 
</PropertyGroup>
    • Добавьте два элемента 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" />
    • Добавьте цель 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 (Debug или Release) , соответствующее тому, какую сборку должен выполнять Team Build.
  8. В разделе Deployment установите флажок Create an IIS virtual directory for the output folder и задайте имя виртуальной папки.
  9. Щелкните OK.
  10. Верните изменения в систему управления исходным кодом.

При выполнении сборки, содержащей это решение, будет создано веб-приложение и виртуальная папка в папке, где выполняется сборка веб-приложения - {Папка сборки}\{Имя командного проекта}\{Тип сборки}\Binaries\ {Название конфигурации}\{Платформа}\_PublishedWebSite\{Имя проекта развертывания веб-приложения.

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

Как с помощью 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 [имя_проекта] /upgrade.
  2. Убедитесь, что на сервере сборки установлен .NET 1.1 Software Develop ment Kit (SDK) .
  3. Скачайте и установите MSBuild Extras (http://www.codeplex.com/MSBee).
  4. Скачайте BuildingFx11inTB.targets с сайта http://blogs.msdn.com/gautamg/ attachment/578915.ashx.
  5. Извлеките для редактирования из системы управления исходным кодом тип сборки, по которому будет выполняться сборка проекта .NET 1.1.
  6. Скопируйте BuildingFx11inTB.targets в папку, содержащую тип сборки, и верните файл в систему управления исходным кодом.
  7. Отредактируйте файл TFSBuild.proj:
    • Импортируйте файл BuildingFx11inTB.targets:
      <Import Project="$(MSBuildProjectDirectory)\BuildingFx11inTB.targets" />
    • Добавьте свойство, определяющее цели CSharp:
      <PropertyGroup> 
 <AdditionalPropertiesForBuildTarget>  
   CustomAfterMicrosoftCommonTargets=$(ProgramFiles)\MSBuild\MSBee\ MSBuildExtras.Fx1_1.CSharp.targets
  </AdditionalPropertiesForBuildTarget> 
</PropertyGroup>
  8. Верните файл TFSBuild.proj в систему управления исходным кодом.

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

<SolutionToBuild Include="$(BuildProjectFolderPath)/path/MySolution. sln">
<Properties>
CustomAfterMicrosoftCommonTargets=$(ProgramFiles)\MSBuild\MSBee\ MSBuildExtras.Fx1_1.CSharp.targets
</Properties> </SolutionToBuild>

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

  • Подробнее о MSBuild Extras читайте в статье "MSBuild Extras - Toolkit for .NET 1.1 "MSBee"" по адресу http://www.codeplex.com/MSBee.
  • Дополнительную информацию об использовании MSBuild Extras для сборки приложений .NET 1.1 вы найдете в статье "Building .NET 1.1 application using Team Build" по адресу http://blogs.msdn.com/gautamg/ar-chive/2006/04/19/578915.aspx.

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

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

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

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

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

Задайте выполнение сборки пакета установки

  1. В Solution Explorer щелкните правой кнопкой мыши проект установки, для которого будет создаваться сценарий сборки.
  2. Щелкните Properties.
  3. Щелкните Configuration Manager.
  4. Выберите необходимые конфигурации ( Debug, Release, обе).
  5. Установите флажок Build для проекта пакета установки.

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

  • Откройте папку решения для проекта пакета установки.
  • Откройте файл .vdproj в любом другом редакторе (не в Visual Studio ).
  • Извлеките файл .vdproj из системы управления исходным кодом для редактирования.
  • Найдите в нем следующие записи: SccLocalPath (локальный путь в системе управления исходным кодом), SccAuxPath (вспомогательный путь в системе управления исходным кодом), OutputFileName (имя выходного файла) и SourcePath (путь к исходному файлу).
  • Убедитесь, что все пути являются относительными, а не абсолютными (по умолчанию они должны быть относительными). Абсолютные пути начинаются с имени диска, а относительные пути - с двойной косой черты (\\) или вообще не имеют никаких дополнительных символов.

  • Все абсолютные пути (если таковые обнаружатся) замените относительными (не меняя константы, которые будут раскрыты программой установки позже), например:

    "OutputFileName" = "8:c:\\temp\\SetupProject.msi"
    замените на
    "OutputFileName" = "8:debug\\SetupProject.msi"

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

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

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

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

  1. Откройте сценарий сборки, который хотите использовать для проекта пакета установки.
  2. Извлеките сценарий сборки из системы управления исходным кодом для редактирования.
    • Файл типа сценария сборки TFSBuild.proj находится в системе управления исходным кодом в папке командного проекта в подпапке папки TeamBuildTypes.
    • Возможно, сначала понадобится выполнить операцию Get Latest Version.

  3. В окне Source Control Explorer щелкните дважды файл TFSBuild.Proj, чтобы открыть его для редактирования.

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

  4. Добавьте следующий код в конец файла между последним тегом </ItemGroup> и последним тегом </Project> :
    <Target Name="AfterCompile">
<Exec Command=""C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv"  
"C:\Documents and Settings\dar-ren\My Documents\Visual Studio 2005\Projects\HelloWorldTest\ 
  HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj"  /Build "Debug""/>
<Copy SourceFiles="C:\Documents and Settings\darren\My Documents\ Visual Studio 2005
  \Projects\HelloWorldTest\HelloWorldTestInstaller\ Debug\HelloWorldTestInstaller.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> в командной строке, заменив " кавычками, например:

    "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv" 
 "C:\Documents and Settings\darren\My Documents\Visual Studio 2005  
   \Projects\HelloWorldTest\HelloWorldTestInstaller\
HelloWorldTestInstaller.vdproj" /Build "Debug"

    Совет Используйте командную строку и для проверки путей Source-Files.

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

  1. В Team Explorer правой кнопкой мыши щелкните тип сборки и выберите команду Build Team Project.
  2. Посмотрите в отчете о результатах сборки, была ли она успешной или дала сбой.
  3. Если сборка дала сбой, щелкните ссылку на протокол сборки. Как правило, причины сбоя таковы:
    • Неверный путь команды exec.
    • Неверно заданы права доступа, из-за чего не удалось скопировать выходные файлы в папку сборки. Убедитесь, что у учетной записи tfsservice есть право копировать файлы из папки двоичных файлов в папку сборки. Папка двоичных файлов - это папка, в которую помещается файл msi после сборки. Папка сборки определена в файле в теге <BuildDirectoryPath> .
    • Неверно заданы права доступа, что препятствует сборке проекта пакета установки. Убедитесь, что учетная запись tfsserver обладает правом чтения файла .vdproj и исходных файлов проекта, а также приложения, с которым связан проект установки. Кроме того, учетной записи tfsserver необходимо право записи двоичных файлов в выходную папку, например, Debug или Release.
    • Неверная конфигурация сборки. Убедитесь, что заданная в теге exec command конфигурация сборки существует. Например, вместо конфигурации "Debug" в проекте может иметься конфигурация "Debug|Any CPU" . Это можно проверить, посмотрев свойства решения в Solution Explorer.
  4. Если в протоколе сборки нет достаточной информации, создайте выходной файл для команды exec и попробуйте найти в нем недостающие сведения. Например:
    <Exec Command=""C:\Program Files\Microsoft Visual Studio 8\Common7\ IDE\devenv"   
  "C:\Documents and Settings\darren\My Documents\ Visual Studio 2005\Projects\HelloWorldTest\HelloWorldTestInstaller\ 
HelloWorldTestInstaller.vdproj" 
  /Build "Debug"  > c:\temp\ output.txt"/>

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

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

Новый сценарий сборки создается из папки Team Builds в Team Explorer.

Создание сценария сборки

  • Откройте Team Explorer.
  • Разверните командный проект, для которого хотите создать тип сборки.
  • Щелкните правой кнопкой мыши папку Team Builds.
  • Выберите команду New Team Build Type.
  • Задайте имя нового типа сборки и щелкните Next.
  • Выберите проекты, которые хотите включить в сборку. Среди них должен быть проект с модульными тестами.
  • Выберите конфигурацию сборки (например, Release или Debug ) и щелкните Next.
  • Задайте имя сервера сборки, например, TFSRTM.
  • Задайте локальную папку сборки на сервере сборки, например, c:\builds.
  • Задайте место накопления результатов сборки, например, \\TFSRTM\ NightlyBuilds, и щелкните Next.
  • Установите флажок Run tests, выберите список тестов, которые хотите связать со сборкой, и щелкните Next.
  • Щелкните Finish, чтобы создать новый тип сборки.

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

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

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

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

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

  1. В Source Control Explorer извлеките для редактирования сценарий TFS-Build.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>
<!-- добавляется по одной записи для каждого используемого проекта --> 
 <Map Include="$/YourApp/YourApp">
   <LocalPath>$(SolutionRoot)\YourApp</LocalPath> </Map> <Map Include="$/DependentApp/DependentApp">
  <LocalPath>$(SolutionRoot)\DependentApp</LocalPath> 
 </Map> 
</ItemGroup>
  4. Переопределите событие BeforeGet, чтобы рабочие области извлекались для каждого командного проекта:
    <Target Name="BeforeGet"> <DeleteWorkspaceTask
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
  Name="$(WorkspaceName)" /> <Exec
  WorkingDirectory="$(SolutionRoot)"
    Command=""$(TfCommand)" workspace /new $(WorkSpaceName) /  
       server:$(TeamFoundationServerUrl)"/> <Exec
  WorkingDirectory="$(SolutionRoot)"
   Command=""$(TfCommand)" workfold /unmap /workspace:$(WorkS
paceName) "$(SolutionRoot)""/> <Exec
   WorkingDirectory="$(SolutionRoot)"
   Command=""$(TfCommand)"  workfold /map /workspace:$(WorkSp aceName) /
    server:$(TeamFoundationServerUrl) "%(Map.Identity)" "%(Map.LocalPath)""/> 
</Target>
  5. Верните изменения сценария в систему управления исходным кодом и выполните сборку.

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

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

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

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

Создание уведомления о выполнении сборки

  1. Щелкните правой кнопкой командный проект в Team Explorer.
  2. Выберите команду Project Alerts.
  3. Выберите все варианты уведомлений, которые хотите получать, и введите адрес электронной почты.

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

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

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

Создание уведомления о сбое сборки

  1. Создайте и протестируйте сборку. Убедитесь, что у вас соответствующий тип сборки и что он выполняется без ошибок.
  2. С помощью инструмента командной строки BisSubscribe.exe подпишитесь на событие BuildCompletionEvent и задайте фильтр, определяющий, что вы хотите получать уведомления по электронной почте только при сбое сборки. Используйте для этого следующий синтаксис:
    bissubscribe /eventType BuildCompletionEvent /address myemail@domain.com 
/deliveryType EmailPlaintext /server tfsserver1 /filter "
TeamProject = 'MyTeamProject'   AND CompletionStatus='Failed'"
  3. Протестируйте сборку. Верните в систему код, который заведомо не компилируется, выполните сборку и убедитесь в получении уведомления по электронной почте.

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

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

Запустить тип сборки можно из папки 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. Агент сборки задается при запуске новой сборки.

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

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

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

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

  1. Откройте Source Control Explorer.
  2. Разверните папку своего командного проекта.
  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 и задайте место публикации.

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

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

Увидеть, какие наборы изменений связаны со сборкой, можно из окна 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 этого курса.

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

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

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

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

  • /Source
    • /WinFormsProject
    • /WebProject
    • /WindowsServiceProject
    • /ClassLibrary1
    • /ClassLibrary2
    • /ClassLibrary3
    • Web.sln
    • Service.sln
    • All.sln

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

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

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

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

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

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

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

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

Отчеты

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

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

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

Просмотр информации о качестве сборки

  1. Откройте Team Explorer.
  2. Разверните проект, для которого хотите посмотреть качество сборки.
  3. Разверните папку Team Builds.
  4. Щелкните дважды тип сборки, качество выполнения которой хотите оценить.

Если используется шаблон процесса 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.

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

  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, результаты тестов верификации сборки ( build verification testing, BVT ) можно найти в отчете Builds.

Просмотр состояния сборки

  1. В Team Explorer разверните узел своего командного проекта.
  2. Щелкните правой кнопкой Reports и выберите команду Show Report Site.
  3. На сайте отчетов выберите отчет Builds.

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

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

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

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

Создание плановой сборки

  1. Создайте строку запуска команды TFSBuild:
    TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>
  2. Поместите строку команды запуска в командный файл.
  3. Создайте задачу планировщика, которая будет выполнять командный файл через заданные промежутки времени.

Подробнее - в разделе "Как настроить плановую сборку в Visual Studio Team Foundation Server " этого курса.

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

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

  • Более подробную информацию вы найдете в лекции 9 этого курса.

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

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

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

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

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

  • Подробнее о настройке плановых сборок читайте в разделе "Как настроить плановую сборку в Visual Studio Team Foundation Server " этого курса.
  • Дополнительную информацию вы найдете в лекции 9 этого курса.

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

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

Как создать простейший приемочный тест

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

Чтобы создать список тестов, связанных со сборкой, необходимо установить 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. Перетащите нужные элементы из списка доступных тестов в свой узел списка тестов.
  10. Верните в систему управления исходным кодом измененный VSMDI -файл проекта модульного теста.

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

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

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

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

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

  1. Создайте один или несколько автоматизированных тестов, которые нужно выполнять в процессе сборки.
  2. В меню Test выберите команду Create New Test List.
  3. С помощью Test Manager сгруппируйте тесты в новый список, перетаскивая их из раздела Test View в Test List.
  4. Создайте новый тип сборки.
  5. Установите флажок автоматизированного тестирования.
  6. Выберите проект, в рамках которого были созданы тесты и список тестов.
  7. Выберите список тестов, который хотите выполнять.

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

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

Включить анализ кода в сценарий сборки можно как при создании нового типа сборки, установив соответствующий флажок в New Team Build Type Creation Wizard, так и позже, изменяя файл TFSBuild.proj.

Включение анализа кода в файле TFSBuild.proj

  • Если требуется, чтобы анализ кода выполнялся для всех проектов, независимо от их настроек, присвойте тегу lt;RunCodeAnalysis> значение Always.
  • Если требуется, чтобы анализ кода выполнялся для проектов соответственно их настройкам, присвойте тегу <RunCodeAnalysis> значение Default.

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

  • Дополнительную информацию об автоматическом анализе кода в ходе сборки вы найдете в разделе "Как автоматически выполнять анализ кода при помощи Team Build " этого курса.
  • Подробнее об инструментах анализа кода читайте в статье "Guidelines for Using Code Analysis Tools" по адресу http://msdn2.microsoft.com/en-us/ library/ms182023(VS.80).aspx.

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

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

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

Завершение сборки сбоем при невыполнении теста

  1. Откройте файл Microsoft.TeamFoundation.Build.targets из папки Program Files\MSBuild\Microsoft\VisualStudio\v8.0\TeamBuild.
  2. Извлеките из системы управления исходным кодом и откройте для редактирования файл TFSBuild.proj для типа сборки, который должен завершаться сбоем в случае непрохождения теста (тестов).
  3. Скопируйте цель RunTestWithConfiguration из Microsoft.TeamFounda-tion.Build.targets в самый конец файла TFSBuild.proj, непосредственно перед закрывающим тегом </Project> .
  4. Измените значение атрибута ContinueOnError с true на false.

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

Если вы хотите, чтобы сборка всегда считалась неудачной при завершении теста с ошибкой, измените непосредственно Microsoft.TeamFoundation. Build.targets. Это повлияет на поведение всех типов командной сборки.

Рекомендованное выше решение легко реализуется, но нет гарантии, что оно будет работать в будущих версиях Visual Studio. Чтобы реализовать решение, которое обязательно будет работать после обновления, читайте статью "Determining Whether Tests Passed in Team Build" в блоге Аарона Холл-берга (Aaron Hallberg) по адресу http://blogs.msdn.com/aaronhallberg/ar-chive/2006/09/21/determining-whether-tests-passed-in-team-build.aspx.

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

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

Дальше >>
< Дополнительный материал 1 || Дополнительный материал 2: 1234567891011 || Дополнительный материал 3 >

Вопросы и ответы

вопросов: 2
Илья Макаренко
Илья Макаренко

Добрый день.

Вопрос №1

Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте?

Вопрос №2

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

ответить
Александр Медов
Александр Медов

Здравствуйте, какова полная сумма предоставленной услуги с печатью документа и отправкой по почте?

ответить

Студенты

всего: 337
dsd dsa
dsd dsa
Китай
предложить дружбу
Иван Циферблат
Иван Циферблат
Россия, Таганрог, 36, 2000
предложить дружбу