Руководства

Руководство по Team Build

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

Стратегия:

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

Ветвление

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

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

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

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

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

Настройка

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

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

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

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

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

Проекты

• Избегайте перекрестных зависимостей между командными проектами.
• Используйте ссылки на проекты вместо ссылок на файлы.
• Используйте Web Deployment Project для веб-приложений.
• Используйте стратегию единого решения при работе над небольшим командным проектом.
• При работе над большим командным проектом с несколькими независимыми подпроектами разделяйте решение на части.
• Используйте несколько решений при работе над очень большим командным проектом с десятками независимых подпроектов.

Сборки по расписанию

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

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

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

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

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

Стратегия

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

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

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

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

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

Создание сборки по расписанию

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Development - ветвь для разработки.
  • Source.
• Main - главная ветвь сборки.
  • Source.
  • Другие папки ресурсов.

При работе с ветвлением принимайте во внимание следующие рекомендации:

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

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

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

• Дополнительную информацию по определению стратегии ветвления и слияния вы найдете в лекции 5 этой книги.
• С общими сведениями о ветвлении и слиянии вас познакомит статья "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181428(VS.80).aspx.
• Дополнительную информацию о ветвлении и слиянии в Visual Studio 2005 вы найдете в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms1 81423(VS.80).aspx.

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

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

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

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

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

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

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

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

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

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

• Дополнительную информацию о создании уведомлений вы найдете в статьях "How to: Receive Build Notification E-Mail" по адресу http://msdn2.microsoft.com/en-us/library/ms181725(VS.80).aspx и "How to: Add or EditAlerts" по адресу http://msdn2.microsoft.com/en-us/library/ms181335(VS.80).aspx.