Руководства

Проекты

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

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

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

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

• Дополнительную информацию о создании рабочей области вы найдете в статье "How to: Create a Workspace" по адресу http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx.
• Дополнительную информацию об изменении рабочей области вы найдете в статье "How to: Edit a Workspace" по адресу http://msdn2.microsoft. com/en-us/library/ms245466(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.

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

Чтобы сослаться на другой файл сборки .NET в том же решении Visual Studio, используйте ссылку на проект Visual Studio. Используя ссылки на проект, вы даете Visual Studio возможность выполнять некоторые вещи автоматически, например, синхронизировать конфигурацию сборки ( debug или release ), отслеживать версии, при необходимости повторно собирать компоненты в случае изменения версии файла сборки .NET.

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

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

Используйте Web Deployment Project для веб-приложений

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

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

• Дополнительную информацию вы найдете в статье "Visual Studio 2005 Web Deployment Projects" по адресу http://msdn2.microsoft.com/en-us/asp.net/aa336619.aspx.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Чтобы анализ кода выполнялся для всех проектов независимо от настроек проекта, измените значение тега

  <RunCodeAnalysis> на Always.
• Чтобы анализ кода выполнялся лишь при условии соответствующей настройки параметров проекта, измените значение тега <RunCodeAnalysis> на Default.

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

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

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

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

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

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

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

• Дополнительную информацию об автоматическом выполнении тестов сборки вы найдете в статье "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.

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

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

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

Настройка сбоя сборки при завершении теста с ошибкой

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

4. Измените атрибут ContinueOnError с true на false.

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

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

   <OnError ExecuteTargets="CreateWorkItem;">

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

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

• Дополнительную информацию о настройке сборки для создания рабочих элементов при завершении теста с ошибкой вы найдете в статье "Create Workitems for Test Failures in TeamBuild" по адресу http://blogs.msdn.com/ nagarajp/archive/2005/10/14/481290.aspx.
• Дополнительную информацию о решении, которое будет работать после обновления Visual Studio, читайте статью "Determining Whether Tests Passed in Team Build" в блоге Аарона Халлберга (Aaron Hallberg) по адресу http://blogs.msdn.com/aaronhallberg/archive/2006/09/21/determining-whether-tests-passed-in-team-build.aspx.

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

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

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

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

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

<!-Создание рабочего элемента для сбоя сборки --> 
 <CreateNewWorkItem BuildId="$(BuildNumber)" Description="$(WorkItemDescription)" 
  TeamProject="$(TeamProject)"
  TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
  Title="$(WorkItemTitle)" WorkItemFieldValues="$(WorkItemFieldValues)" 
     WorkItemType="$(WorkItemType)" ContinueOnError="true" />

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

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

• Дополнительную информацию о настройке рабочих элементов ошибки сборки вы найдете в статье "Team Foundation Build Tasks" по адресу http://msdn2.microsoft.com/en-us/library/ms243778(vs.80).aspx.

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

• Дополнительные сведения о командных сборках вы найдете в статье "Overview of Team Foundation Build" по адресу http://msdn2.microsoft. com/en-us/library/ms181710(VS.80).aspx.