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

Разбить на страницы

Показывать лекцию целиком

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

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

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

Как защитить сервер сборки.

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

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

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

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

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

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

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

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

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

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

Настройка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проекты

Как применять стратегию с одиночным решением.

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

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

Отчеты

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

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

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

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

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

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

Как просмотреть состояние сборки.

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

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

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

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

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

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

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

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

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

Как защитить сервер сборки.

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

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

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

Как защитить сервер сборки

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

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

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

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

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

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

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

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

Подробную информацию о группах .

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

Для удаления сборок используется инструмент командной строки myproject build20070606.4

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

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

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

Дополнительную информацию о команде delete вы найдете в статье "Delete Command (Team Foundation Build)" по адресу http://msdn2. microsoft.com/en-us/library/ms244360(VS.80).aspx.

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

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

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

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

Разверните папку своего командного проекта.

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

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

Еще раз щелкните правой кнопкой мыши папку Team Build и выберите Check In Pending Changes.

Откройте Team Explorer.

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

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

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

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

Более подробно о .

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

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

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

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

Верните ожидающие изменения в систему управления исходным кодом.

В диалоговом окне Check In щелкните Work Items.

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

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

Подробнее о возврате ожидающих изменений читайте в статье "How to:Check In Pending Changes" по адресу http://msdn2.microsoft.com/en-us/library/ms181411(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.

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

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

Включение политики связи возврата изменений с рабочими элементами

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

Перейдите на вкладку Check-in Policy.

Щелкните Add. Выберите и настройте политику возврата Work Item.

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

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

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

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

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

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

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

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

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

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

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

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

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

Bissubscribe /eventType CheckinEvent /address 
  http://TFSRTM:8080/ci/no-tify.asmx /deliveryType Soap /domain http://TFSRTM:8080

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

Настройте рассылку уведомлений по электронной почте Они проинформируют заинтересованные стороны о завершении сборки. При помощи контекстного меню командного проекта откройте диалоговое окно 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 " этого курса.

Дополнительную информацию об использовании непрерывной интеграции в .

Скачать .

Подробнее о гибкой разработке и непрерывной интеграции в .

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

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

продолжительность сборки Team Build в минутах;

средний интервал между последовательными возвратами после правки в минутах;

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

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

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

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

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

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

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

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

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

Настройка

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

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

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

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

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

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

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

Настройка номера сборки в файле сборке и в интерфейсе Team Build

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

Переопределите цель 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, вам следует сопоставлять только эту папку.

Сокрытие папки

Извлеките для правки файл WorkspaceMapping.xml.

Добавьте в файл записи о сокрытии.

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

<Mappings>
<InternalMapping ServerItem="$/MyTeamProject" LocalItem="c:\projects\ teamproject" Type="Map" />
<InternalMapping ServerItem="$/MyTeamProject/documentation" Type="Cloak" /> </Mappings>

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

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

Дополнительную информацию о сокрытии папок в рабочей области вы найдете в статье "How to: Cloak and Decloak Folders in a Workspace" по адресу http://msdn2.microsoft.com/en-us/library/ms181378(VS.80).aspx.

Дополнительную информацию об исключении папок при командной сборке вы найдете в статье "How to make 'Team Build' skip getting certain folders?" по адресу http://blogs.msdn.com/manishagarwal/archive/2005/10 /13/480584.aspx.

Дополнительную информацию о схеме .

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

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

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

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

В разделе PropertyGroup (группа свойств) добавьте следующие параметры:

<!-- должны находиться под PropertyGroup -->
<TfCommand>$(TeamBuildRefPath)\..\tf.exe</TfCommand>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>

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

Добавьте следующие параметры в элементы 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>

Переопределите событие 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>

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

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

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

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

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

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

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

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

Разверните папку своего командного проекта.

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

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

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

Чтобы открыть TFSBuild.Proj, в окне Source Control Explorer щелкните его дважды.

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

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

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

Подробнее о настройке .

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

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

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

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

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

Установка сервера сборки

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

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

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

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

В папке на DVD -диске Team Foundation Server откройте папку uild.

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

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

должна обладать разрешением 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

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

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

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

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

В раскрывающемся списке Platform выберите платформу .NET

Задайте расположение типа сборки.

Выберите тесты и правила анализа кода.

Сохраните тип сборки, щелкнув Finish.

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

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

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

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

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

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

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

Задайте расположение типа сборки.

Выберите тесты и правила анализа кода.

Сохраните тип сборки, щелкнув Finish.

Местом накопления скомпилированных двоичных файлов будет папка {Тип сборки}\{Название конфигурации}\{Платформа}\_PublishedWebsites.

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

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

Послесборочный этап для развертывания веб-приложения

Скачайте библиотеку .

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

Из скачанного zip -архива извлеките файл Microsoft.Sdc.Tasks.dll и поместите его в ту же в папку, что и тип сборки.

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

Внесите правки в файл 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>

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

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

Проект развертывания веб-приложения

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

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

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

В меню Build выберите команду Add Web Deployment Project.

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

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

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

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

Щелкните OK.

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

При выполнении сборки, содержащей это решение, будет создано веб-приложение и виртуальная папка в папке, где выполняется сборка веб-приложения - {Папка сборки}\{Имя командного проекта}\{Тип сборки}\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

Обновите решения .NET 1.1 до .NET 2.0. Для этого откройте решение в Visual Studio 2005 и запустите Conversion Wizard или выполните команду devenv [имя_проекта] /upgrade.

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

Скачайте и установите ).

Скачайте .

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

Скопируйте BuildingFx11inTB.targets в папку, содержащую тип сборки, и верните файл в систему управления исходным кодом.

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

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

<Import Project="$(MSBuildProjectDirectory)\BuildingFx11inTB.targets" />

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

<PropertyGroup> 
 <AdditionalPropertiesForBuildTarget>  
   CustomAfterMicrosoftCommonTargets=$(ProgramFiles)\MSBuild\MSBee\ MSBuildExtras.Fx1_1.CSharp.targets
  </AdditionalPropertiesForBuildTarget> 
</PropertyGroup>

Верните файл 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>

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

Подробнее о .

Дополнительную информацию об использовании .

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

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

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

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

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

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

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

Щелкните Properties.

Щелкните Configuration Manager.

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

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

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

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

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

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

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

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

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

"OutputFileName" = "8:c:\\temp\\SetupProject.msi"

замените на

"OutputFileName" = "8:debug\\SetupProject.msi"

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

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

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

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

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

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

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

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

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

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

Добавьте следующий код в конец файла между последним тегом </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>

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

Совет Проверьте путь из тега <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.

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

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

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

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

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

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

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

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

Если в протоколе сборки нет достаточной информации, создайте выходной файл для команды 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"/>

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

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

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

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

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

Откройте Team Explorer.

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

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

Выберите команду New Team Build Type.

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

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

Выберите конфигурацию сборки (например, Release или Debug ) и щелкните Next.

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

Задайте локальную папку сборки на сервере сборки, например, c:uilds.

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

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

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

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

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

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

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

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

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

Под разделом PropertyGroup добавьте следующие параметры:

<!-- добавить под PropertyGroup -->
<TfCommand>$(TeamBuildRefPath)\..\tf.exe</TfCommand>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>

Добавьте следующие параметры в элементы 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>

Переопределите событие 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>

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

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

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

Дополнительную информацию вы найдете в статье "Working with multiple team projects in Team Build" по адресу http://blogs.msdn.com/man-ishagarwal/archive/2005/12/22/506635.aspx.

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

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

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

Щелкните правой кнопкой командный проект в Team Explorer.

Выберите команду Project Alerts.

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

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

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

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

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

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

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

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

bissubscribe /eventType BuildCompletionEvent /address myemail@domain.com 
/deliveryType EmailPlaintext /server tfsserver1 /filter "
TeamProject = 'MyTeamProject'   AND CompletionStatus='Failed'"

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

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

Дополнительную информацию о фильтрах событий завершения сборки вы найдете в статье "How to Filter the Build Completion Event" по адресу http://blogs.msdn.com/jpricket/archive/2006/09/05/how-to-filter-the-build-completion-event.aspx.

Подробнее о фильтрах .

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

Запустить тип сборки можно из папки Team Builds в Team Explorer. Ручной запуск сборки

Откройте Team Explorer.

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

Разверните папку Team Builds.

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

Выберите команду Build Team Project.

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

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

Проверка успешного выполнения сборки

Откройте Team Explorer.

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

Разверните папку Team Builds.

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

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

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

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

Откройте Team Explorer.

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

Разверните папку Team Builds.

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

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

Чтобы просмотреть папку с результатом сборки, щелкните ссылку Build name.

Чтобы просмотреть протокол сборки, щелкните ссылку Log.

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

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

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

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

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

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

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

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

Чтобы открыть TFSBuild.Proj, щелкните его дважды в Source Control Explorer.

Измените тег <BuildMachine> , подставив в него указание на другой сервер.

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

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

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

Подробнее о настройке .

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

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

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

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

Разверните папку своего командного проекта.

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

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

Чтобы открыть TFSBuild.Proj, щелкните его дважды в Source Control Explorer.

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

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

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

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

Подробнее о настройке .

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

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

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

Откройте Team Explorer.

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

Разверните папку Team Builds.

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

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

Разверните элемент Associated changesets.

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

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

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

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

Откройте Team Explorer.

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

Разверните папку Team Builds.

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

В раскрывающемся списке 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.

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

Откройте Team Explorer.

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

Разверните папку Team Builds.

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

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

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

В Team Explorer разверните узел нужного командного проекта.

Щелкните правой кнопкой Reports и выберите команду Show Report Site.

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

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

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

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

Откройте Team Explorer.

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

Разверните папку Team Builds.

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

Щелкните дважды результирующий элемент Team Build, для которого хотите увидеть возвраты изменений.

Разверните элемент Associated changesets, чтобы просмотреть возвраты изменений, связанные со сборкой.

Чтобы получить больше информации по конкретному набору изменений, щелкните ссылку ID.

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

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

Просмотр закрытых рабочих элементов, связанных со сборкой

Откройте Team Explorer.

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

Разверните папку Team Builds.

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

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

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

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

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

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

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

Щелкните правой кнопкой Reports и выберите команду Show Report Site.

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

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

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

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

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

Щелкните правой кнопкой Reports и выберите команду Show Report Site.

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

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

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

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

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

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

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

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

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

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

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

Щелкните правой кнопкой Reports и выберите команду Show Report Site.

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

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

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

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

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

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

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

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

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

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

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

Подробнее - в разделе "Как настроить плановую сборку в 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.

Создание приемочного теста

В меню Test выберите команду New Test.

Щелкните Unit Test и OK.

Введите имя проекта и щелкните Create.

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

Верните проект в систему управления исходным кодом.

В Visual Studio, открыв решение модульного теста, в меню Test выберите команду Create New Test List.

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

В диспетчере Test Manager щелкните узел All Loaded Tests.

Перетащите нужные элементы из списка доступных тестов в свой узел списка тестов.

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

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

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

Подробнее об автоматическом выполнении тестов верификации сборки читайте в статье "How to: Configure and Run Build Verification Tests (BVTs)" по адресу http://msdn2.microsoft.com/en-us/library/ms182465(VS.80).aspx.

Об автоматизированном тестировании сборки без .

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

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

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

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

В меню Test выберите команду Create New Test List.

С помощью Test Manager сгруппируйте тесты в новый список, перетаскивая их из раздела Test View в Test List.

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

Установите флажок автоматизированного тестирования.

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

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

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

Об автоматизированном тестировании сборки без .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительную информацию о настройке сборки для создания рабочих элементов при завершении теста с ошибкой вы найдете в статье "Create Workitems for Test Failures in TeamBuild" по адресу http://blogs.msdn.com/ nagarajp/archive/2005/10/14/481290.aspx.

Дополнительную информацию о решении, которое будет работать после обновления .

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

Более общую информацию о .

Практические рекомендации: управление проектом

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

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

Как повысить качество кода при помощи политики возврата после правки.

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

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

Управление проектом

Как управлять проектом при помощи Microsoft Project.

Как управлять проектом при помощи Microsoft Excel.

Как создать минимальный шаблон процесса.

Как настроить шаблон процесса.

Как настроить тип рабочего элемента в шаблоне процесса.

Как настроить тип рабочего элемента в существующем командном проекте.

Как создать итерацию.

Как создать область.

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

Как настроить панель отчетов.

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

Как удалить проект из Team Foundation Server.

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

Как повысить качество кода при помощи политики возврата после правки.

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

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

Как повысить качество кода при помощи политики возврата после правки

Сочетая политики анализа и тестирования, вы обеспечите соблюдение стандартов качества кода. Например, встроенная в VSTS политика тестирования обеспечит обязательное проведение специальных тестов перед возвратом кода в систему управления исходным кодом Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) . Также можно настроить политику анализа кода, обеспечив с ее помощью соответствие кода определенным нормам безопасности, производительности, переносимости, удобства сопровождения и надежности.

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

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

В окне Team Explorer щелкните правой кнопкой нужный командный проект, раскройте подменю Team Project Settings и выберите команду Source Control.

Перейдите на вкладку Check-in Policy.

Щелкните кнопку Add, а затем выберите и настройте соответствующую политику.

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

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

Дополнительную информацию о настройке политики возврата после правки вы найдете в статье "Walkthrough: Customizing Check-in Policies and Notes" по адресу http://msdn2.microsoft.com/en-us/library/ms181281 (VS.80).aspx.

С примером кода, запрещающего определенные варианты программирования, можно ознакомиться по материалам статьи "Checkin Policy to Disallow Certain Patterns" по адресу http://blogs.msdn.com/jmanning/archive/2 006/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/ar-chive/2006/02/07/526778.aspx.

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

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

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

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

Перейдите на вкладку Check-in Policy.

Щелкните кнопку Add, а затем выделите и настройте политику Work Item.

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

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

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

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

В окне Team Explorer правой кнопкой мыши щелкните нужный командный проект, раскройте подменю Team Project Settings и щелкните команду Source Control.

Перейдите на вкладку Check-in Policy и щелкните кнопку Add.

В диалоговом окне Add Check-in Policy установите параметр Code Analysis и щелкните OK.

В редакторе Code Analysis Policy Editor задайте параметр Enforce C/ C++ Code Analysis (/analyze), Enforce Code Analysis For Managed Code или оба, если ваш проект содержит сочетание управляемого и неуправляемого кода.

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

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

С примером кода, запрещающего определенные варианты программирования, можно познакомиться в статье "Checkin Policy to Disallow Certain Patterns" по адресу http://blogs.msdn.com/jmanning/archive/2006/02/02/5 23125.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/ar-chive/2006/02/07/526778.aspx.

Управление проектом

Как управлять проектом при помощи Microsoft Project.

Как управлять проектом при помощи Microsoft Excel.

Как создать минимальный шаблон процесса.

Как настроить шаблон процесса.

Как настроить тип рабочего элемента в шаблоне процесса.

Как настроить тип рабочего элемента в существующем командном проекте.

Как создать итерацию.

Как создать область.

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

Как настроить панель отчетов.

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

Как удалить проект из Team Foundation Server.

Как управлять проектом при помощи Microsoft Project

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

Создать план проекта.

Составить набор задач, разработать для них расписание и опубликовать их в Team Foundation Server.

Эти задачи отображаются в очереди рабочих элементов соответствующего разработчика.

Члены команды работают над заданиями и сообщают о продвижении работ в Team Explorer, устанавливая статус рабочего объекта.

Обновить план проекта для извлечения актуальной информации. Это позволяет следить за развитием проекта в Microsoft Project.

Публикация плана проекта в TFS

Создавая план нового проекта, определите задачи, время их выполнения, распределение ресурсов, зависимости и другие сведения, которые вы обычно задаете в Microsoft Office Project.

В окне Microsoft Office Project в меню Team выберите команду Choose Team Project.

Выберите Team Foundation Server для своего командного проекта.

Выделите свой командный проект.

Щелкните OK.

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

В столбце Sync выберите вариант Do Not Publish для суммарных задач, которые не хотите публиковать в TFS.

Если у вас есть задачи, назначенные более чем одному ресурсу, разделите их на отдельные задачи, порученные одному ресурсу. (В настоящий момент Team Foundation Server не поддерживает назначения рабочего элемента нескольким ресурсам.) При необходимости сгруппируйте отдельные задачи в суммарную задачу, чтобы получить возможность пользоваться автоматическим вычислением.

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

Щелкните команду Publish на панели инструментов Work Item, чтобы опубликовать план проекта в TFS.

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

Дополнительную информацию о работе с рабочими элементами в .

Дополнительную информацию об импорте рабочих элементов вы найдете в статье "How to: Import Work Items in Microsoft Excel or Microsoft Project" по адресу http://msdn2.microsoft.com/en-us/library/ms181676(VS.80).aspx.

Дополнительную информацию об управлении проектом в .

Как управлять проектом при помощи Microsoft Excel

Используйте Microsoft Office Excel® для хранения, сортировки, фильтрования и управления требованиями, сценариями, проблемами, ошибками, рисками и рабочими элементами.

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

Создание списка рабочих элементов в Excel

В окне Microsoft Office Excel выберите в меню Team команду New List.

В окне Connect to a Team Foundation Server выберите сервер, к которому нужно подключиться, или щелкните Servers для ввода информации о сервере вручную.

В окне Team Projects выберите командный проект на сервере TFS, с которым хотите работать. Документ привязан к командному проекту.

Щелкните OK.

Выберите тип списка. Чтобы создать список на базе запроса выберите Query List и выберите запрос в раскрывающемся списке Select a Query.

Укажите столбцы, которые должны присутствовать в новом списке рабочих элементов.

Импортируйте нужные рабочие элементы.

Сохраните электронную таблицу или опубликуйте новые рабочие элементы в БД рабочих элементов, выбрав команду Publish Changes в меню Team.

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

Дополнительную информацию о работе со списками рабочих элементов вы найдете в статье "Working with Work Item Lists in Microsoft Excel" по адресу http://msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx.

Дополнительную информацию о создании списков рабочих элементов вы найдете в статье "How to: Create a Work Item List" по адресу http:// msdn2.microsoft.com/en-us/library/ms181695(VS.80).aspx.

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

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

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

В окне Team Explorer щелкните правой кнопкой имя сервера. Затем выберите команды Team Foundation Server Settings и Process Template Manager.

Выберите шаблон, который хотите редактировать, и щелкните команду Download.

В папке, в которой вы сохранили шаблон, откройте для редактирования файл Process Template.xml.

Введите в элемент <name> имя процесса.

В разделе <plugins> удалите модули Reporting, Portal и WorkItemTracking.

В разделе <groups> удалите группы Reporting, Portal и WorkItemTracking.

В группе VersionControl найдите раздел <dependencies> и удалите зависимость WorkItemTracking.

Удалите из папки, в которой сохранен шаблон, подпапки Reports, Windows Sharepoint Services и WorkItem Tracking.

Сохраните изменения.

В окне Team Explorer щелкните правой кнопкой имя сервера и выберите команды Team Foundation Server Settings и Process Template Manager.

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

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

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

Дополнительную информацию о настройке шаблона процесса вы найдете в разделе "Как настроить шаблон процесса в .

Как настроить шаблон процесса

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

Настройка шаблона процесса

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

Загрузите шаблон выбранного процесса.

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

Выгрузите настроенный шаблон в TFS.

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

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

Вручную отредактировать XML-файлы. Любое действие вручную чревато многочисленными ошибками, но с другой стороны оно позволяет настроить шаблон с высочайшей точностью.

Воспользоваться инструментом Process Template Editor из комплекта Microsoft Visual Studio 2005 Team Foundation Server Power Tool - графическим редактором для просмотра и настройки шаблонов процесса. Подключившись к TFS, его можно использовать для настройки определений типов рабочих элементов и глобальных списков активного проекта.

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

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

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

Для настройки типа рабочего элемента используется инструмент .

Настройка типов рабочего элемента

Загрузите наиболее подходящий шаблон, выполнив следующие действия:

В Visual Studio выберите в меню Team команду Team Foundation Server Settings.

Щелкните Process Template Manager.

В диалоговом окне Process Template Manager выберите шаблон процесса, который хотите изменить, и щелкните кнопку Download.

Выберите папку на локальном диске, в которой хотите сохранить шаблон, и щелкните кнопку Save.

Откройте шаблон процесса в Process Editor и отредактируйте типы рабочих элементов, как описано ниже:

В окне Visual Studio откройте меню Team.

Щелкните Process Editor и Open Process Template.

В диалоговом окне Open Process Template fileset перейдите к загруженному шаблону процесса и щелкните Open. Файл ProcessTemplate.xml будет загружен в Visual Studio.

Задайте имя для настраиваемой методологии.

В окне Process Template Explorer щелкните кнопку Work Item Tracking.

Перейдите на вкладку Type Definition.

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

В диалоговом окне New Work Item Type введите имя типа рабочего элемента и выберите существующий тип рабочего элемента из раскрывающегося списка Copy From. Создается новый тип рабочего элемента, отображающийся в списке Item List на правой панели вкладки Type Definition.

Чтобы сохранить изменения, выберите в меню File команду Save.

На вкладке Type Definitions щелкните правой кнопкой тип рабочих элементов, который хотите отредактировать, и выберите команду Open. Выбранный тип откроется в новом окне Visual Studio.

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

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

Загрузить .

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

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

Есть два способа редактирования существующего типа рабочего элемента: из командной строки и при помощи инструмента Process Template Editor из комплекта TFS Power Tool.

Для редактирования типа рабочего элемента из командной строки используются инструменты witexport и witimport, которые находятся в папке %programfiles%\Program Files\Microsoft Visual Studio 8\Common7\IDE компьютера, на котором установлен Team Explorer.

Экспорт, редактирование и импорт типа рабочего элемента

Запустите команду witexport, как показано ниже, чтобы экспортировать тип рабочего элемента:

witexport /f task.xml /t http://TFSServer:8080 /p MyTeamProject /n Task

Отредактируйте определение типа рабочего элемента.

Запустите команду witimport, как показано ниже, чтобы импортировать измененный тип:

witimport /f task.xml /t http://TFSServer:8080 /p MyTeamProject

В предыдущем примере подразумевается экспорт типа рабочего элемента Task из проекта MyTeamProject на сервер с именем TFSServer.

Редактирование типа рабочего элемента с помощью Process Template Editor

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

В окне Visual Studio в меню Team выберите команду Process Template Editor. Затем щелкните Work Item Types и выберите Export WIT.

В диалоговом окне Connect to Team Foundation Server введите URL сервера.

В диалоговом окне Select Work Item Type выберите тип рабочего элемента, экспорт которого хотите осуществить.

Сохраните тип рабочего элемента.

Сохраните все глобальные списки, которые собираетесь редактировать.

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

В Visual Studio в меню Team выберите команду Process Editor. Затем щелкните Work Item Types и выберите Import WIT.

В диалоговом окне Connect to Team Foundation Server введите URL сервера.

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

Щелкните OK.

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

Загрузить .

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

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

Как создать итерацию

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

Создание итерации

В Team Explorer щелкните командный проект.

В меню Team раскройте подменю Team Project Settings и выберите команду Areas and Iterations.

В диалоговом окне Areas and Iterations перейдите на вкладку Iteration.

Щелкните кнопку Add a child node на панели инструментов.

Щелкните правой кнопкой новый узел, выберите команду Rename и введите имя итерации.

Щелкните узел Iteration.

Повторите шаги 2, 3 и 4, чтобы создать дополнительные итерации.

Щелкните Close.

Примечание В шаблон процесса MS Agile включены три предопределенные итерации. При необходимости вы вольны, удалить эти итерации, переименовать их или оставить неизменными.

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

Дополнительную информацию вы найдете в статье "Walkthrough: Creating a New Team Project" по адресу http://msdn2.microsoft.com/en-us/ library/dhedaeb2(VS.80).aspx.

Как создать область

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

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

Создание областей

В Team Explorer щелкните ваш проект.

В меню Team раскройте подменю Team Project Settings и выберите команду Areas and Iterations.

В диалоговом окне Areas and Iterations перейдите на вкладку Area.

Щелкните кнопку Add a child node на панели инструментов.

Щелкните новый узел правой кнопкой, выберите команду Rename и введите имя области.

Щелкните узел Area.

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

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

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

Для подписки на уведомления о возврате после правки используется инструмент bissubscribe, расположенный в папке %programfiles%\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup на сервере TFS.

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

Откройте командную строку и перейдите в папку C:\Program Files\ Microsoft Visual Studio 2005 Team Foundation Server\TF Setup\.

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

bissubscribe /eventType CheckinEvent /address someone@domain.com / deliveryType EmailHtml /domain http://TFSRTM:8080

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

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

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

Откройте SQL Server Management Studio.

Откройте БД tfsIntegration.

Просмотрите таблицу tbl_subscription.

В таблице tbl_subscription перечислены все события, на которые задана подписка. Найдите в этой таблице записи о событиях, на которые вы подписаны. Чтобы отписаться от события, удалите из таблицы запись о нем или воспользуйтесь командой bissubscribe с параметром /unsubscribe и идентификатором события, например:

bissubscribe /delete/id [id] /server http://TFSRTM:8080

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

Дополнительную информацию о непрерывной сборке вы найдете в разделе "Как настроить непрерывную сборку в .

Дополнительную информацию об использовании команды .

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

Чтобы собрать разнообразную информацию о проекте в одном месте, создайте на портале командного проекта Microsoft Office SharePoint® панель отчетов ( report dashboard ). Вот список отчетов, которые на ней можно разместить:

Remaining Work Оставшаяся работа.

Quality Indicators Показатели качества.

Bug Rates Частота появления ошибок.

Project Velocity Темп выполнения проекта.

В каждый отчет, который вы хотите отобразить на панели, нужно добавить веб-часть Report Viewer.

Изменение портала командного проекта и создание панели отчетов

Установите веб-часть Report Viewer на сервер отчетов. Для этого используются инструмент stsadm.exe и файл RSWebParts.cab, входящие в дистрибутив Microsoft Office SharePoint и Report Services.

Инструмент STSADM.EXE находится в папке C:\Program Files\ Common Files\Microsoft Shared\web server extensions\60\BIN.

Файл RSWebParts.Cab находится в папке C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint.

Пример использования:

STSADM.EXE -o addwppack -filename 
 "C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint\RSWebParts.cab" -globalin-stall

В Team Explorer щелкните правой кнопкой нужный проект и выберите команду Show Project Portal.

Щелкните Modify Shared Page, разверните подменю Browse и выберите команду Add Web Parts.

Щелкните Virtual Server Gallery.

В списке Web Part List выберите вариант Report Viewer.

Щелкните кнопку Add.

Введите имя диспетчера отчетов ( Report Manager ), например,

http:// <сервер отчетов>/reports

Введите путь к отчету, который хотите отобразить, например, <мой проект>/Quality Indicators.

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

Дополнительную информацию о добавлении компонента .

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

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

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

Создание структуры папок на сервере

В Team Explorer разверните нужный командный проект.

Дважды щелкните Source Control.

В окне Source Control Explorer выберите корневой узел, щелкните правой кнопкой панель Local Path и выберите команду New Folder.

Введите имя корневой папки и нажмите Enter.

Повторяйте шаги 3 и 4 для создания других папок в хранилище системы управления исходным кодом.

Создание структуры папок на клиенте

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

Создайте требующуюся для проекта структуру папок.

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

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

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

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

Как удалить проект из Team Foundation Server

Средствами Team Explorer удалить проект нельзя, придется воспользоваться инструментом командной строки TfsDeleteProject. Он находится в папке Program Files\Microsoft Visual Studio 8\Common7\IDE на компьютере, где установлен Team Explorer.

Удаление проекта из TFS

Откройте командную строку и перейдите в папку C:\Program Files\ Microsoft Visual Studio 2005 Team Foundation Server\TF Setup\.

Запустите команду TfsDeleteProject, как показано в примере: TfsDeleteProject /server:TfsServer TeamProjectName

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

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

Дополнительные ресурсы по управлению проектами Team Foundation

Дополнительную информацию о шаблонах процесса .

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

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

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

Как создать панель отчетов.

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

Создание и настройка

Как модифицировать существующий отчет.

Как создать новый отчет в Visual Studio.

Как создать новый отчет в Excel.

Как создать снимок отчета по расписанию.

Как подписаться на отчет.

Как добавить отчет в существующий шаблон процесса.

Просмотр

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

Как проанализировать качество приложения.

Как просмотреть оставшуюся работу.

Как просмотреть состояние сборки.

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

Как сравнить запланированную работу с фактической.

Как определить владельца последней редакции файла.

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

Как найти все изменения, внесенные в файл.

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

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

Как сгенерировать показатели рабочей области (файлов, строки кода, количество проектов).

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

Как создать панель отчетов.

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

Как создать панель отчетов

Модифицируйте сайт портала Microsoft® Office SharePoint® командного проекта, чтобы создать панель отчета. Она позволяет обобщать разнообразную информацию проекта в едином расположении. Функциональная панель отчетов должна, вероятно, включать следующие отчеты:

об оставшейся работе;

о показателях качества;

о частоте появления ошибок;

о темпе продвижения проекта.

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

Изменение портала командного проекта и создание панели отчетов

Установите компонент Report Viewer Web Part на сервер отчетов. Для этого используются инструмент stsadm.exe и файл RSWebParts.cab, которые входят в дистрибутив Microsoft Office SharePoint и Report Services, например:

STSADM.EXE -o addwppack -filename 
 "C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint\RSWebParts.cab" -globalinstall

Инструмент STSADM.EXE находится в папке C:\Program Files\Com-mon Files\Microsoft Shared\web server extensions\60\BIN.

Файл RSWebParts.Cab находится в папке C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint.

В Team Explorer щелкните правой кнопкой ваш проект.

Выберите команду Show Project Portal.

Щелкните Modify Shared Page.

Наведите указатель на Browse и щелкните Add Web Parts.

Щелкните Virtual Server Gallery.

В списке Web Part List выберите вариант Report Viewer.

Щелкните кнопку Add.

Введите имя диспетчера отчетов, например, http://<сервер отчетов>/reports.

Введите путь отчета, который хотите отобразить, например: <мой проект>/Quality Indicators.

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

Дополнительную информацию о добавлении компонента .

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

При помощи списка разрешений отчета вы определяете пользователей, которым можно редактировать и просматривать отчеты. Для установки разрешений вы должны быть членом роли Content Manager в Microsoft SQL Server™ Reporting Services.

Предоставление разрешение на доступ ко всем отчетам командного проекта

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

Щелкните правой кнопкой элемент Reports и выберите команду Show Report Site.

Перейдите на вкладку Properties.

Щелкните Security.

Щелкните Edit Item Security.

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

Чтобы задать разрешения безопасности для роли, которой нет в списке, щелкните New Role Assignment.

Установка разрешений для одного отчета

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

Щелкните правой кнопкой элемент Reports и выберите Show Report Site.

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

Перейдите на вкладку Properties.

Щелкните Security.

Щелкните Edit Item Security.

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

Чтобы задать разрешения безопасности для роли, которой нет в списке, щелкните New Role Assignment.

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

Дополнительную информацию о разрешениях отчетов вы найдете в статье "How to: Set Permissions for a Report" по адресу http://msdn2.microsoft.com/en-us/library/ms181645(VS.80).aspx.

Создание и настройка

Как модифицировать существующий отчет.

Как создать новый отчет в Visual Studio.

Как создать новый отчет в Excel.

Как создать снимок отчета по расписанию.

Как подписаться на отчет.

Как добавить отчет в существующий шаблон процесса.

Как модифицировать существующий отчет

Существующие отчеты модифицируются при помощи инструмента Microsoft SQL Server™ 2005 Reporting Services Designer, входящего в Visual Studio (Business Intelligence Development Studio) , который поставляется с клиентскими инструментами SQL Server 2005. Часто модифицировать существующий отчет проще, чем создать новый.

Создание проекта отчета

В Visual Studio откройте меню File и выберите команды New и Project.

Выберите тип отчета Business Intelligence Project.

Выберите шаблон Report Server Project.

Укажите имя проекта в поле Name и его расположение в поле Location. Щелкните OK.

Экспорт модифицируемого отчета

Щелкните проект правой кнопкой и в контекстном меню выберите команду Show Project Portal.

На панели Quick Launch, находящейся слева, щелкните Reports.

Выделите отчет, который хотите настроить.

Щелкните Properties.

Выберите Edit.

Сохраните файл отчета .rdl в папке проекта, созданного ранее.

Добавление источников данных

Создайте источник данных хранилища:

В окне Visual Studio Solution Explorer щелкните правой кнопкой Shared Data Sources и выберите команду Add New Data Source.

На вкладке General введите TfsReportDS в текстовое поле Name.

В списке Type выберите Microsoft SQL Server.

Щелкните Edit.

Введите имя сервера уровня данных.

Выберите базу данных TFSWarehouse.

Дважды щелкните ОК, чтобы добавить источник данных.

Создайте источник данных OLAP:

В окне Visual Studio Solution Explorer щелкните правой кнопкой Shared Data Sources и выберите команду Add New Data Source.

На вкладке General введите TfsOlapReportDS в поле Name.

В списке Type выберите Microsoft SQL Server.

Щелкните Edit.

Введите имя сервера уровня данных.

Выберите базу данных TFSWarehouse.

Дважды щелкните ОК, чтобы добавить источник данных.

Добавление отчета в проект

В окне Solution Explorer щелкните правой кнопкой Reports, затем щелкните Add и Existing Item.

Найдите файлу .rdl, экспорт которого выполнили ранее.

Редактирование отчета

Измените операторы запросов на панели данных.

Перетащите на панель данных новые критерии или членов.

Измените разметку отчета на панели Layout Pane.

Примечание Вы, конечно, можете использовать построитель отчетов ( Report Builder ), который имеется на сайте отчетов команды, но этот инструмент не очень хорошо поддерживается сценариями отчетов Visual Studio, поэтому работать с ним не рекомендуется.

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

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

Как создать новый отчет в Visual Studio

Создание отчетов также осуществляется при помощи инструмента Microsoft SQL Server™ 2005 Reporting Services Designer, входящего в Visual Studio (Business Intelligence Development Studio) из клиентского комплекта SQL Server 2005.

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

Создание проекта отчета

В Visual Studio откройте меню File и выберите команды New и Project.

Выберите тип отчета Business Intelligence Project.

Выберите шаблон Report Server Project.

Укажите имя проекта в поле Name и его расположение в поле Location. Щелкните OK.

Добавление источников данных

Создайте источник данных хранилища:

В окне Visual Studio Solution Explorer щелкните правой кнопкой Shared Data Sources и выберите команду Add New Data Source.

На вкладке General введите TfsReportDS в текстовое поле Name.

В списке Type выберите Microsoft SQL Server.

Щелкните Edit.

Введите имя сервера уровня данных.

Выберите базу данных TFSWarehouse.

Дважды щелкните ОК, чтобы добавить источник данных.

Создайте источник данных OLAP:

В окне Visual Studio Solution Explorer щелкните правой кнопкой Shared Data Sources и выберите команду Add New Data Source.

На вкладке General введите TfsOlapReportDS в поле Name.

В списке Type выберите Microsoft SQL Server.

Щелкните Edit.

Введите имя сервера уровня данных.

Выберите базу данных TFSWarehouse.

Дважды щелкните ОК, чтобы добавить источник данных.

Создание нового шаблона

В окне Solution Explorer щелкните правой кнопкой Reports и выберите команды Add и New Item.

Выберите шаблон Report.

Присвойте имя шаблону и щелкните OK.

Редактирование шаблона

Если окно Report Designer не открывается автоматически, откройте отчет для редактирования, дважды щелкнув его в Solution Explorer.

В раскрывающемся списке Dataset выберите вариант New Dataset.

Задайте имя набора данных, например, TestDataSet.

Задайте параметр TFSOlapReportDS (shared) .

Щелкните OK.

Щелкните многоточие рядом с кнопкой Build (прямо под списком Dataset ), после чего выберите Team System.

Теперь вы можете изменять отчет, перетаскивая меры и измерения из дерева Dataset на панели Query и Filter. Макет шаблона изменяется на вкладке Layout. Предварительно просмотреть отчет можно на вкладке Preview.

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

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

Как создать новый отчет в Excel

Вы можете создавать пользовательские отчеты, подключив Microsoft Office Excel® напрямую к кубу TFS Reporting OLAP. Excel позволяет отображать данные отчета в форме сводных таблиц или сводных диаграмм.

Создание отчета в форме сводной таблицы Excel

Убедитесь, что у вас установлен поставщик .

Запустите Excel.

Выберите электронную таблицу, к которой хотите добавить сводную таблицу.

В меню Data выберите команду PivotTable and PivotChart Report.

Выберите External Data Source.

Щелкните Next.

Щелкните Get Data.

Перейдите на вкладку OLAP Cubes.

Выберите New Data Source и щелкните OK.

Введите имя источника данных.

Выберите поставщик Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB.

Щелкните Connect.

Выберите Analysis Server.

Введите имя сервера отчетов, например, TFSRTM.

Щелкните Next.

Выберите TFSWarehouse и щелкните Finish.

Выберите куб, из которого хотите создать отчет (например, Code Churn, Work Items, Test Result ) и щелкните OK.

Еще раз щелкните OK, чтобы вернуться в мастер Pivot Table and Pivot Chart Wizard.

Щелкните Finish, чтобы добавить сводную таблицу на лист. Перетащите столбцы и измерения в сводную таблицу из списка PivotTable Field List.

Ниже приведен пример отображения количества строк для каждого командного проекта на сервере:

На шаге 17 выберите куб Code Churn.

Перетащите TeamProject.TeamProject в раздел Column Fields сводной таблицы.

Перетащите Total Lines в раздел Data Items сводной таблицы.

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

Дополнительную информацию о создании отчетов с помощью .

Загрузить .

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

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

Плановое создание снимка отчета

В окне Team Explorer правой кнопкой щелкните Reports и выберите команду Show Report Site.

Откройте отчет на сайте отчетов.

Перейдите на вкладку Properties.

Щелкните ссылку History.

Установите расписание для запуска снимка.

После создания расписания вы сможете просматривать отчеты на вкладке History данного отчета. Там же можно создавать снимки вручную.

Как подписаться на отчет

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

Создание подписки на отчет

В окне Team Explorer щелкните правой кнопкой Reports и выберите команду Show Report Site.

Откройте отчет на сайте отчетов.

Перейдите на вкладку Subscriptions.

Щелкните New Subscription, чтобы создать новую подписку.

Как добавить отчет в существующий шаблон процесса

Для добавления новых отчетов в существующий шаблон процесса применяется инструмент .

Добавление нового отчета

Загрузите шаблон процесса, наиболее отвечающий вашим требованиям:

В окне Visual Studio щелкните Team и выберите Team Foundation Server Settings.

Щелкните Process Template Manager.

В диалоговом окне Process Template Manager выберите шаблон процесса, который хотите изменить, и щелкните Download.

В диалоговом окне Process Template Manager выберите расположение на локальном диске и щелкните Save.

Откройте шаблон процесса в окне Process Editor:

В окне Visual Studio раскройте меню Team.

Выберите Process Editor и щелкните Open Process Template.

В диалоговом окне Open Process Template fileset перейдите к загруженному шаблону процесса, а затем щелкните Open. В окне Visual Studio откроется файл ProcessTemplate.xml.

Заполните поле Name (имя) для методологии, к которой вы применяете настройки.

В окне Process Template Explorer щелкните Reports.

На панели инструментов щелкните Add.

На вкладке Report Detail диалогового окна Report введите имя отчета.

Перейдите в расположение файла .rdl, который хотите добавить в поле File Name. Остальные поля оставьте без изменений. Не следует также вносить изменения в данные, содержащиеся на вкладках Properties и Parameters.

На вкладке DataSources введите источники данных. Стандартные источники данных для шаблонов процесса, поставляющихся с TFS, - /TfsOlapReportDS и /TfsReportDS.

Щелкните OK.

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

Загрузить инструментарий .

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

Просмотр

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

Как проанализировать качество приложения.

Как просмотреть оставшуюся работу.

Как просмотреть состояние сборки.

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

Как сравнить запланированную работу с фактической.

Как определить владельца последней редакции файла.

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

Как найти все изменения, внесенные в файл.

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

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

Как сгенерировать показатели рабочей области (файлов, строки кода, количество проектов).

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

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

Просмотр состояния приложения

В окне Team Explorer разверните узел проекта, щелкните правой кнопкой Reports и выберите команду Show Report Site.

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

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

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

Анализ качества приложения

В окне Team Explorer разверните узел проекта, щелкните правой кнопкой Reports и выберите команду Show Report Site.

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

Как просмотреть оставшуюся работу

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

Просмотр оставшейся части работы

В окне Team Explorer разверните узел проекта, щелкните правой кнопкой Reports и выберите команду Show Report Site.

На сайте отчетов выберите отчет Remaining Work.

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

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

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

В окне Team Explorer разверните узел проекта, щелкните правой кнопкой Reports и выберите команду Show Report Site.

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

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

Для просмотра ошибок используется отчет Bugs by Priority, отображающий соотношение высокоприоритетных и низкоприоритетных ошибок. Отчет Quality Indicators универсален - он применяется для просмотра результатов тестов, ошибок, покрытия кода тестами и изменяемости кода.

Просмотр ошибок и результатов тестов

В окне Team Explorer разверните узел проекта, щелкните правой кнопкой Reports и выберите команду Show Report Site.

На сайте отчетов выберите отчет Bugs by Priority для просмотра ошибок или отчет Quality Indicators для просмотра результатов тестов.

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

Для сравнения запланированной и реально выполненной работы используйте отчет Unplanned Work. Он отображает полную работу в сравнении с оставшейся работой, а также отделяет запланированные задачи от внеплановых.

Просмотр отчета Unplanned Work

В окне Team Explorer разверните узел проекта, щелкните правой кнопкой Reports и выберите команду Show Report Site.

На сайте отчетов выберите отчет Unplanned Work.

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

Для определения владельца последней редакции файла воспользуйтесь историей файла в окне Source Control Explorer.

Определение пользователя, изменившего файл последним

В окне Source Control Explorer выберите нужный файл.

Щелкните его правой кнопкой мыши и выберите команду View History.

На панели History просмотрите историю изменений, включая их автора.

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

Дополнительную информацию о .

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

Чтобы найти все изменения, внесенные в код проекта конкретным разработчиком, пользуйтесь командой TF History. Вот как выглядит команда, отображающая все изменения, внесенные пользователем Mario:

tf history $/ /r /user:Mario

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

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

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

Как найти все изменения, внесенные в файл

При помощи истории файла исходного кода можно из окна Source Control Explorer находить изменения, внесенные в файл.

Определение всех изменений, внесенных в файл

В окне Source Control Explorer выберите нужный файл.

Щелкните его правой кнопкой мыши и выберите команду View History.

На панели History просмотрите историю изменений.

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

Дополнительную информацию о .

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

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

Просмотр изменений кода, связанных с рабочим элементом

Откройте интересующий вас рабочий элемент.

Перейдите на вкладку Links. Если с рабочим элементом связан набор изменений, он будет перечислен в списке на панели Links.

Дважды щелкните набор изменений для просмотра возвращенных файлов и комментариев.

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

Дополнительную информацию о наборах изменений вы найдете в статье "Working with Source Control Changesets" по адресу http://msdn2. microsoft.com/en-us/library/ms181408(VS.80).aspx.

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

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

Просмотр отчета Quality Indicators

В окне Team Explorer разверните узел проекта, щелкните правой кнопкой Reports и выберите команду Show Report Site.

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

В качестве альтернативы вы можете генерировать отчет об изменяемости кода в Excel. Дополнительные сведения содержатся в разделе "Как создать новый отчет в Excel" этой лекции.

Как сгенерировать показатели рабочей области (файлов, строки кода, количество проектов)

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

Создание сводной таблицы Excel

Убедитесь, что у вас установлен поставщик .

Запустите Excel.

Выберите электронную таблицу, к которой хотите добавить сводную таблицу.

В меню Data выберите команду PivotTable and PivotChart Report.

Выберите External Data Source.

Щелкните Next.

Щелкните Get Data.

Перейдите на вкладку OLAP Cubes.

Выберите New Data Source и щелкните OK.

Введите имя источника данных.

Выберите поставщик Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB.

Щелкните Connect.

Выберите Analysis Server.

Введите имя сервера отчетов, например, TFSRTM.

Щелкните Next.

Выберите TFSWarehouse и щелкните Finish.

Выберите куб Code Churn и щелкните OK.

Еще раз щелкните OK, чтобы вернуться в мастер Pivot Table and Pivot Chart Wizard.

Щелкните Finish, чтобы добавить сводную таблицу на лист.

При помощи списка PivotTable Field List перетащите в сводную таблицу столбцы и меры.

Подсчет файлов в каждом командном проекте

Перетащите элемент TeamProject.TeamProject в раздел Page Fields сводной таблицы.

Перетащите FileName.FilePath в раздел Row Fields сводной таблицы.

Для фильтрации по командным проектам используйте раскрывающийся список Team Project в разделе Page Fields. Обратите внимание на количество отображенных строк. Это и есть количество файлов.

Подсчет строк в каждом командном проекте

Перетащите элемент TeamProject.TeamProject в раздел Column Fields сводной таблицы.

Перетащите Total Lines в раздел Data Items сводной таблицы.

Подсчет командных проектов, находящихся на сервере

Перетащите элемент TeamProject.TeamProject в раздел Row Fields сводной таблицы.

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

Дополнительную информацию об использовании .

Загрузить .

Дополнительные ресурсы по отчетам Team Foundation

Дополнительную информацию об отчетах вы найдете в статье "Team Foundation Server Reporting" по адресу http://msdn2.microsoft.com/en-us/library/ms194922(VS.80).aspx.

Практические рекомендации: система управления исходным кодом

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

Доступ к системе управления версиями

Как работать с системой управления версиями на клиентах, работающих не под управлением Visual Studio.

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

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

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

Как добавить нового разработчика в проект.

Как удалить покидающего команду разработчика.

Как предоставлять разрешения в пределах дерева исходного кода.

Как переместить систему управления версиями Team Foundation Server на другой сервер.

Ветвление, метки и слияние

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

Как выполнять ветвление.

Как планировать структуру ветвей.

Как осуществлять поддержку выпуска при помощи ветвления.

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

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

Как стабилизировать разработку функций при помощи ветвления.

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

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

Как прекратить поддержку старого выпуска.

Как выполнять слияние.

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

Как разрешать конфликты слияния.

Как избегать конфликтов.

Сборки

Как с помощью TFS производить непрерывную сборку.

Возврат после правки и соответствующие политики

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

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

Как перекрыть политику возврата после правки.

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

Как создать пользовательскую политику возврата после правки.

Отладка, извлечение и блокировка

Как синхронизировать компьютер с TFS.

Как подготовить файл к редактированию.

Совместное использование кода

Как организовать общий доступ к коду.

Как управлять общими двоичными файлами.

Зависимости

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

Как управлять зависимостями БД.

Распределенная и удаленная разработка

Как получить доступ к TFS через Интернет.

Как повысить производительность TFS -прокси.

Миграция

Как осуществить перенос исходного кода с Visual SourceSafe.

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

Управление проектом и рабочей областью

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

Как организовать дерево исходного кода.

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

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

Безопасность

Как защитить канал между рабочей станцией разработчика и TFS.

Отложенные правки

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

Как с помощью отложенных правок передать код другому члену команды.

Доступ к системе управления версиями

Как работать с системой управления версиями на клиентах, работающих не под управлением Visual Studio.

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

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

Как работать с системой управления версиями на клиентах, работающих не под управлением Visual Studio

Чтобы получить доступ к системе управления версиями Microsoft® Visual Studio® 2005 Team System (VSTS) Team Foundation Server (TFS) , работая на клиентах под управлением других систем, воспользуйтесь следующими способами:

интеграцией при помощи Microsoft Source Code Control Interface (MSSCCI) ;

интеграцией при помощи продуктов сторонних производителей;

пользовательской интеграцией.

Интеграция при помощи MSSCCI

Ниже приведен список клиентов, способных работать с системой управления версиями TFS через поставщика MSSCCI:

Microsoft Visual Studio .NET 2003.

Microsoft Visual C++® 6 SP6.

Microsoft Visual Basic® 6 SP6.

Microsoft Visual FoxPro® 9 SP1.

Microsoft Access™ 2003 SP2.

Microsoft SQL Server™ Management Studio.

Sparx Systems Enterprise Architect 61.

Sybase PowerBuilder 105.

Toad for SQL Server 2.0.

Загрузить провайдер .

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

Для следующих клиентов существуют решения интеграции, предлагаемые независимыми производителями:

Eclipse.

Клиент Linux.

Клиент Apple Macintosh.

Веб-клиент HTML.

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

Пользовательская интеграция

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

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

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

Дополнительную информацию о работе с управляющими сценариями и командными файлами вы найдете в статье "Team Foundation Source Control Scripts and Command Files" на сайте MSDN по адресу http:// msdn2.microsoft.com/en-us/library/1az5ay5c(VS80).aspx.

Дополнительную информацию о расширяемости системы .

Дополнительную информацию о работе с системой управления версиями .

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

Автоматизация наиболее распространенных задач, связанных с управлением версиями, осуществляется с помощью инструмента командной строки tf. exe. Он позволяет выполнять те же действия, что и Source Control Explorer, включая операции управления исходным кодом ( add, check-in, checkout, get, lock, label и т. д.), ветвление, создание отложенных правок, манипуляции с рабочей областью и основные административные функции.

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

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

отмена извлечения файлов другим пользователем для редактирования;

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

определение области видимости метки;

выполнение слияния без основы.

Чтобы правильно установить пути и других переменные среды, следует запускать инструмент из окна командной строки Visual Studio 2005 или выполнить пакетный файл Vsvars32, который, как правило, расположен в папке Диск:\Program Files\Microsoft Visual Studio 8\Common7\Tools.

Инструмент Tf.exe устанавливается в составе клиента TFS и по умолчанию расположен в папке C:\Program Files\Microsoft Visual Studio 8\Common 7\IDE.

При запуске инструмента командной строки следует задать имя сервера при помощи параметра /s. Далее приведен пример команды, отображающей файлы в системе управления исходным кодом, расположенной на сервере YourTFSServer: tf.exe dir /s:YourTFSServer

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

Дополнительную информацию о работе с командной строкой вы найдете в статье "Walkthrough: Working with Team Foundation Source Control from Command Line" на сайте

Справочную информацию о работе с командной строкой вы найдете в статье "MSDN Team Foundation Source Control Command-Line Reference" по адресу http://msdn2.microsoft.com/en-us/library/cc31bk2e(VS.80).aspx.

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

Автономный режим работы системой управления версиями TFS не поддерживается. Чтобы все-таки поработать автономно, вы должны в точности выполнить следующие действия:

Вручную снять флаги "только для чтения". По умолчанию все файлы в рабочей области, не извлеченные для правки, доступны только для чтения. При отсутствии подключения к серверу, прежде чем редактировать или удалять файлы, вы должны вручную снять с них флажки "только для чтения". Щелкните файл правой кнопкой в проводнике Windows, выберите команду Свойства (Properties) , снимите флажок Только чтение (Read-only) и щелкните OK. То же действие можно выполнить с помощью команды attrib -r.

Отредактируйте файлы, с которых сняли метку "только для чтения".

Добавьте или удалите файлы, с которых сняли метку "только для чтения". Не переименовывайте файлы, потому что инструмент TFTP online не способен отличить операцию переименования ( rename ) от операции удаления ( delete ) в сочетании с операцией добавления ( add ).

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

Запустите команду TFPT online, вернувшись в оперативный режим работы. Для этого нужно ввести в командной строке TFTP online. Эта команда проверит рабочую область на предмет наличия записываемых файлов и определит, какие изменения следует отправить на сервер. Если вы удалили какие-либо файлы, задайте параметр /delete. Затем инструмент отобразит окно оперативного режима, в котором можно выбрать, какие изменения следует перенести в вашу рабочую область.

Важно! Во время автономной работы нельзя переименовывать файлы.

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

Загрузить .

Дополнительную информацию об инструменте .

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

Как добавить нового разработчика в проект.

Как удалить покидающего команду разработчика.

Как предоставлять разрешения в пределах дерева исходного кода.

Как переместить систему управления версиями Team Foundation Server на другой сервер.

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

Чтобы подключить к работе нового разработчика, предоставьте ему доступ к соответствующему командному проекту и связанному с ним сайту Microsoft Office SharePoint®. Чтобы разработчик мог просматривать отчеты, предоставьте учетной записи разработчика доступ к SQL Server Reporting Services.

Предоставление доступа к командному проекту

Войдите в систему Visual Studio с учетной записью, входящую в группу администраторов Team Foundation.

Добавьте нужный проект в Team Explorer, если его там еще нет.

Щелкните правой кнопкой командный проект, раскройте подменю Team Project Settings и выберите команду Group Membership.

Выберите вариант Project\Contributors, щелкните Properties и добавьте в эту группу учетную запись нового разработчика.

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

Предоставление доступа к сайту SharePoint

Войдите на сайт командного проекта с учетной записью группы .

Щелкните Site Settings.

Под заголовком Administration щелкните Manage Users.

Щелкните кнопку Add Users.

Введите имя учетной записи нового разработчика в формате домен\имя_ пользователя, выберите группу Contributor и щелкните кнопку Next.

Введите электронный адрес разработчика и, при желании, его приветственное сообщение на сайте.

Щелкните кнопку Finish.

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

Предоставление доступа к SQL Server Reporting Services

Войдите на административный сайт .

Щелкните имя вашего командного проекта.

Перейдите на вкладку Properties.

Перейдите на вкладку Security.

Щелкните New Role Assignment.

Введите имя учетной записи Windows вашего разработчика, выберите вариант Browser и щелкните OK.

Примечание Членство в группе Browser позволяет разработчику просматривать отчеты и подписываться на них.

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

Дополнительную информацию о группах, разрешениях и ролях вы найдете в статье "Team Foundation Server Default Groups, Permissions, and Roles" на сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/ ms253077.aspx.

Дополнительную информацию о правах и разрешениях вы найдете в статье "Source Control Security Rights and Permissions" на сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/ms181761 .aspx.

Как удалить покидающего команду разработчика

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

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

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

tf workspaces /owner:domain\devuser /computer:* /server:servername

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

tf workspace /delete workspacename;domain\devuser /s:servername

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

Командный проект TFS Войдите в Visual Studio с учетной записью из группы администраторов Team Foundation. В окне Team Explorer щелкните правой кнопкой нужный проект, раскройте подменю Team Project Settings, выберите команду Group Membership и удалите ученую запись разработчика из соответствующих групп (как правило, Contributors).

Сайт проекта SharePoint Войдите на сайт команды, расположенный по адресу http://server/sites/ИмяВашегоПроекта/default.aspx, с учетной записью администратора. Щелкните Site Settings, Manage Users и удалите учетную запись разработчика.

SQL Server Reporting Services Войдите на административный сайт SQL Server Reporting Services с учетной записью администратора. Сайт расположен по адресу http://server/reports. Щелкните имя командного проекта, перейдите на вкладку Properties, затем на вкладку Security и удалите учетную запись разработчика.

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

Дополнительные сведения о корректном удалении разработчика, выходящего из проекта, вы найдете в статье "How to: Clean Up Files When Users Leave" по адресу http://msdn2.microsoft.com/en-us/library/ms194958 (VS.80).aspx.

Дополнительную информацию о команде .

Дополнительную информацию о поиске отложенных правок вы найдете в статье "How do I tell who has files checked out or locked?" по адресу http:// blogs.vertigosoftware.com/teamsystem/archive/2006/07/24/3125.aspx.

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

Вы можете предоставлять разрешения в пределах дерева исходного кода. Для этого в обозревателе Source Control щелкните правой кнопкой папку или файл и выберите команду Properties. Перейдите на вкладку Security, выберите группу пользователей, разрешения которой хотите изменить, и внесите нужные исправления. Можно также установить разрешения с помощью утилиты командной строки tf.exe с параметром Permissions.

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

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

Дополнительную информацию о группах, разрешениях и ролях вы найдете в статье "Team Foundation Server Default Groups, Permissions, and Roles" на сайте .

Дополнительную информацию о правах и разрешениях вы найдете в статье "Source Control Security Rights and Permissions" на сайте .

Дополнительную информацию о параметрах команды .

Как переместить систему управления версиями Team Foundation Server на другой сервер

Система Team Foundation Server не поддерживает ни копирование сервера из одного расположения в другое, ни зеркалирование. Вы можете создавать и восстанавливать резервные копии всего сервера, перемещать оборудование сервера в новый домен или выполнить обновление до раздельной системы развертывания. Нельзя осуществлять частичное перемещение, например, переместить одни проекты и оставить другие.

Система Team Foundation Server поддерживает три типа переноса:

Восстановление из резервной копии Этот тип используется для переноса .

Среда Этот тип используется при переноса сервера .

Перенося Team Foundation Server, учитывайте следующие моменты:

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

При изменении имени сервера перестанут работать все документы Microsoft Office, связанные с запросами. Документы привязаны к серверу, для которого были созданы. Это относится ко всем документам Microsoft Office, формируемым при помощи запросов и создаваемым автоматически в узле Documents во время разработки проекта.

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

На исходном TFS существовали локальные учетные записи. Вам предстоит решить, как воссоздавать их: как локальные учетные записи на перенесенном сервере TFS или как доменные учетные записи в новом домене перенесенного TFS.

Допустим, на исходном TFS существовали доменные учетные записи, и вы перемещаете TFS в другой домен, у которого нет доверительных отношений с первоначальным доменом. Решите, что лучше: воссоздать учетные записи на перенесенном TFS как локальные, или создать доменные учетные записи в новом домене перенесенного сервера TFS.

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

Все ли элементы перенесены правильно? Проверьте дерево исходного кода, рабочие элементы и страницы команды.

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

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

Дополнительные сведения о перемещении .

Ветвление, метки и слияние

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

Как выполнять ветвление.

Как планировать структуру ветвей.

Как осуществлять поддержку выпуска при помощи ветвления.

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

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

Как стабилизировать разработку функций при помощи ветвления.

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

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

Как прекратить поддержку старого выпуска.

Как выполнять слияние.

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

Как разрешать конфликты слияния.

Как избегать конфликтов.

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

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

Присвоение метки файлу или папке

Щелкните правой кнопкой файл или папку в окне обозревателя Source Control и выберите команду Apply Label.

В диалоговом окне Choose Item Version уточните имя файла или папки, выберите версию файла или папки, которую хотите пометить, и щелкните OK, чтобы применить метку.

При применении меток следует учитывать следующее:

Метку можно применить только к одной версии файла или папки.

Одной версии файла можно присвоить несколько меток.

Метки, присваиваемые в Source Control Explorer, автоматически видны в корневой папке проекта, внутри которого они были созданы. Нельзя создать две метки с одинаковыми именами в одной зоне видимости.

Метки не имеют версий, и с ними не связанно никакой истории.

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

Система Team Build автоматически присваивает метки набору файлов, задействованному в любой создаваемой ею сборке.

Метки не применяются к удаляемым объектам. Это означает, что при слиянии на основе меток не будет выполнен перенос удаляемых файлов.

Поиск существующей метки

В меню File откройте подменю Source Control, затем выберите команду Label, щелкните Find Label и перейдите в расположение метки.

Найдя метку, вы можете в диалоговом окне Find Label изменить или удалить ее.

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

Дополнительную информацию об использовании меток вы найдете в статье "Working with Labels" по адресу http://msdn2.microsoft.com/en-us/ library/ms181439(VS.80).aspx.

Дополнительную информацию о применении меток вы найдете в статье "How to: Apply Labels" по адресу http://msdn2.microsoft.com/en-us/library/ ms181440(VS.80).aspx.

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

Чтобы создать ветвь, используйте Source Control Explorer или команду tf branch из командной строки.

Для реализации ветвления из Source Control Explorer щелкните правой кнопкой папку самого высокого уровня с исходным кодом вашего проекта, выберите команду Branch и укажите расположение и имя конечной папки, поясняющее назначение ветви, например, MyProject_Release1.0_Branch.

Чтобы выполнить ветвление из командной строки Visual Studio 2005, используйте команду tf branch, например: tf branch C:\MyProject $/MyProject_Release1.0_Branch

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

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

Вводный курс по ветвлению и слиянию вы найдете в статье "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.

Дополнительную информацию о методах ветвления и слияния в .

Как планировать структуру ветвей

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

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

Ветвь обслуживания Обслуживание выпущенной ранее сборки.

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

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

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

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

Дополнительную информацию о методах ветвления и слияния в Visual Studio 2005 вы найдете в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms 181423(VS.80).aspx.

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

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

После ветвления структура папок будет выглядеть примерно так:

Main - главная ветвь сборки.

Source.

Другие папки ресурсов.

Releases - контейнер для ветвей выпусков.

Release 1 - ветвь выпуска.

Source.

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

Когда выполнять ветвление Когда вы готовы к выпуску, соберите все в главную ветвь ( Main ), а затем создайте ветвь выпуска ( Release ), целью которой будет стабилизация приложения перед выпуском.

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

Разрешения в ветви

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

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

Частота производства сборок в ветви Сборки производятся по мере необходимости.

Тесты в ветви Прекращаются после выпуска.

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

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

Дополнительную информауию о методах ветвления и слияния в .

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

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

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

Main - Главная ветвь сборки.

Source.

Другие папки ресурсов.

Releases - контейнер для ветвей выпусков.

Release 1 - ветвь сопровождения.

Source.

Другие папки ресурсов.

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

Когда выполнять ветвление После выпуска.

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

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

Частота производства сборок в ветви Сборки производятся по мере необходимости.

Тесты в ветви Не проводятся.

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

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

Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181428(VS.80).aspx

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

Во избежание ошибок сборки проводите активную разработку в ветви Development, а общую сборку - в ветви Main. Примерно так будет выглядеть структура ветвей после создания ветви разработки Development:

Development - ветвь разработки.

Source.

Main - главная ветвь сборки.

Source.

Другие папки ресурсов.

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

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

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

Разрешения на доступ к ветви

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

Ветвь Development должна быть доступна всем для чтения и записи.

Частота производства сборок в ветви

В ветви Main - ежедневно.

В ветви Development - непрерывная сборка.

Тесты в ветви

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

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

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

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

Дополнительную информацию о методах ветвления и слияния в .

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

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

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

Development - контейнер для ветвей функций.

Функция А - ветвь функции.

Source.

Функция Б - ветвь функции.

Source.

Функция В - ветвь функции.

Source.

Main - главная ветвь сборки.

Source.

Другие папки ресурсов.

Учитывайте следующие рекомендации по работе с ветвью функции:

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

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

Частота производства сборок в ветви В этой ветви производится непрерывная сборка.

Тесты в ветви Производятся испытания функций и беглое тестирование сборки.

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

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

Дополнительную информацию о методах ветвления и слияния в .

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

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

Development - контейнер для ветвей команд.

Team 1 - ветвь команды.

Source.

Team 2 - ветвь команды.

Source.

Main - главная ветвь сборки.

Source.

Другие папки ресурсов.

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

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

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

Разрешения на доступ к ветви Предоставьте разрешения на чтение и запись членам команды, остальным - разрешения только на чтение.

Частота производства сборок в ветви Производится непрерывная сборка.

Тесты в ветви Производятся испытания функций и беглое тестирование сборки.

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

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

Дополнительную информацию о методах ветвления и слияния в .

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

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

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

External - ветвь внешней зависимости.

Source.

Main - главная ветвь сборки.

Source.

Другие папки ресурсов.

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

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

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

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

Частота производства сборок в ветви Сборки производятся по мере необходимости.

Тесты в ветви Проверка взаимодействия и функционирования компонентов.

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

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

Дополнительную информацию о методах ветвления и слияния в .

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

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

Main - главная ветвь сборки.

Source.

Другие папки ресурсов.

Releases - контейнер для ветвей выпусков.

Release 2 - ветвь сопровождения.

Source.

Другие папки ресурсов.

Архив - контейнер для архивного хранения ветвей.

Release 1 - архивная ветвь.

Source.

Другие папки ресурсов.

Перемещая ветви из папки Releases в архив, вы разгружаете папку Releases и одновременно сохраняете старые выпуски. Это не создание новой ветви, а, скорее, перемещение старой ветви в новую папку.

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

Дополнительную информацию о методах ветвления и слияния в .

Как выполнять слияние

Слияние заключается в переносе изменений из одной ветви в другую. Его можно выполнять, используя возможности обозревателя Source Control или команду tf merge. Слияние выполняется по набору изменений, метке, дате или версии. Чтобы приступить к слиянию, щелкните правой кнопкой ветвь в Source Control и выберите команду Merge. Мастер Source Control Merge Wizard поможет выбрать целевую ветвь (в которую будет выполнено слияние).

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

Имейте в виду, что слияние вдоль иерархии - от родительской к дочерней ветви или от дочерней к родительской ветви - завершается с меньшим количеством конфликтов, чем слияние поперек иерархии. Иерархия ветвей основана на родительских и дочерних ветвях и может отличаться от физической структуры, которую вы видите в Source Control. Например:

Физическая структура.

Development - ветвь разработки.

Main - главная ветвь сборки.

Releases - контейнер для ветвей выпусков.

Release 1 - ветвь выпуска.

Логическая структура.

Main.

Development.

Release 1.

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

Дополнительную информацию о слиянии вы найдете в статье "Under standing Merging" по адресу http://msdn2.microsoft.com/en-us/library/ms181427(VS.80).aspx.

О том, как выполнить слияние, читайте в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx.

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

Слияние без основы производится при помощи команды tf merge /baseless из командной строки Visual Studio 2005.

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

merge /baseless <<путь_к_источнику>> <<конечный_путь>> /recursive

Например,

tf merge /baseless c:\data\proj1 c:\data proj2 /recursive

Процесс переноса элементов ветвей, не являющихся прямыми ветвями друг друга, называется слиянием без основы ( baseless merge ). Слиянием без основы можно считать слияние изменений между двумя ветвями выпусков, находящимися на одном уровне, но не имеющих общей родительской ветви. Слияние без основы выполнимо только из командной строки; из Visual Studio его осуществить нельзя.

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

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

Описание синтаксиса команды merge вы найдете в статье "Merge Command" по адресу http://msdn2.microsoft.com/en-us/library/bd6dxhfy(VS.80).aspx.

Дополнительную информацию о слиянии вы найдете в статье "Understanding Merging" по адресу http://msdn2.microsoft.com/en-us/library/ms 181427(VS.80).aspx.

О том, как выполнить слияние, читайте в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library/ms181428 (VS.80).aspx.

Как разрешать конфликты слияния

Для разрешения конфликтов слияния используйте инструментарий слияния Visual Studio. Обнаружив конфликт в процессе слияния, вы можете разрешить его автоматически или вручную. Разрешая конфликт вручную, вы вольны сохранить изменения из исходной ветви, сохранить изменения из целевой ветви или разрешить конфликт при помощи инструмента слияния. Необходимость в разрешении конфликтов возникает при выполнении слияния ветвей, извлечении файлов в рабочую область или возврате новых версий файлов. Существуют три типа конфликтов:

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

Неоднозначность имени файла Два или несколько элементов пытаются занять одно расположение.

Локальная перезапись Возникает только во время выполнения операции get при попытке перезаписать редактируемый файл. Большинство конфликтов может быть разрешено автоматически.

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

В обеих ветвях было выполнено редактирование файла, затронувшее одинаковые строки кода.

Проводится слияние без основы, когда TFS не известны связи файлов ветвей.

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

Разрешив все конфликты в файле, сохраните окончательную версию как незавершенное изменение в целевой ветви.

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

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

Дополнительную информацию о разрешении конфликтов вы найдете в статье "How to: Resolve Conflicts" по адресу http://msdn2.microsoft.com/en-us/library/ms181433(VS.80).aspx.

Как избегать конфликтов

Во избежание конфликтов, сделайте следующее:

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

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

Просмотр незавершенных изменений

В окне Source Control щелкните правой кнопкой решение, проект, папку или файл, для которых хотите просмотреть незавершенные изменения.

Выберите команду View Pending Changes.

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

tf status /format:detailed /user:*

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

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

Дополнительную информацию о просмотре незавершенных изменений в своей рабочей области вы найдете в статье "How to: View and Manage All Pending Changes in Your Workspace" по адресу http://msdn2.microsoft.com/ en-us/library/ms181400(VS.80).aspx.

Дополнительную информацию о просмотре незавершенных изменений в других рабочих областях вы найдете в статье "How to: View Pending Changes in Other Workspaces" по адресу http://msdn2.microsoft.com/en-us/library/ms181401(VS.80).aspx.

Дополнительную информацию о команде .

Сборки

Как с помощью TFS производить непрерывную сборку.

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

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

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

Загрузить веб-службу для запуска процесса сборки, разработанную в Майкрософт, можно из источника, расположенного по адресу http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi.

Возврат после правки и соответствующие политики

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

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

Как перекрыть политику возврата после правки.

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

Как создать пользовательскую политику возврата после правки.

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

Набор изменений ( changeset ) представляет собой совокупность изменений, связанных с конкретным возвратом после правки. Вот список наиболее распространенных действий, применимых к наборам изменений:

возврат набора изменений, связанного с рабочим элементом;

задание метки набора изменений;

просмотр свойств набора изменений;

изменение свойств набора изменений;

отмена набора изменений.

Возврат набора изменений, связанного с рабочим элементом

В Visual Studio откройте меню View, раскройте подменю Other Windows и выберите команду Pending Changes.

Введите комментарий, поясняющий характер изменений.

Щелкните значок Work Items, чтобы раскрыть список рабочих элементов, связанных с набором.

Обновите список рабочих элементов: выделите элемент и укажите нужное действие- Associate или Resolve (если возврат после правки подразумевает разрешение рабочего элемента).

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

Задание метки набора изменений

В окне обозревателя Source Control щелкните правой кнопкой папку с командным проектом и выберите команду Apply Label.

В раскрывающемся списке Version выберите вариант Changeset, введите номер в поле Changeset number и щелкните OK.

В диалоговом окне Apply Label введите имя метки и комментарий. Щелкните OK.

Просмотр свойств набора изменений

Производится с помощью команды tf changeset. Далее приведен пример команды, отображающей в диалоговом окне Details for Changeset свойства набора изменений под номером 1234: tf changeset 1234

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

Изменение свойств набора изменений

Используйте команду tf changeset, чтобы изменить комментарии и примечания, связанные с набором изменений. Приведенная ниже команда вызывает диалоговое окно Details for Changeset со свойствами набора под номером 1234 и обновляет поле комментария.

tf changeset /comment:"Этот комментарий гораздо лучше предыдущего." 1234

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

tf changeset /notes:"Code Reviewer"="C Davis";"Security Reviewer"="F Smith" 1234

Отмена набора изменений

Чтобы откатить набор изменений и удалить его с сервера управления исходным кодом, используется команда Tfpt rollback из комплекта Team Foundation Power Tool. В следующем примере производится откат набора изменений под номером 1234.

TFPT rollback /changeset:1234

Эта команда открывает окно Roll Back Changeset, в котором можно выбрать файлы из набора изменений для отката.

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

Дополнительную информацию о команде .

Дополнительную информацию об извлечении наборов изменений вы найдете в статье "How to: Retrieve Old Versions of Files from Changesets" по адресу http://msdn2.microsoft.com/en-us/library/ms181416(VS.80).aspx.

Загрузить инструмент .

Дополнительные сведения об инструменте .

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

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

По умолчанию, доступны следующие политики:

Code Analysis Требует выполнения анализа кода перед возвратом.

Test Policy Требует проведения тестов перед возвратом.

Work Items Требует, чтобы с возвратом был связан один или несколько рабочих элементов.

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

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

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

Щелкните Check-in Policy и Add.

В списке Check-in Policy выберите вариант Code Analysis и щелкните OK.

Укажите нужный тип анализа кода, установив соответствующий флажок. При выборе варианта Enforce Code Analysis For Managed Code укажите требуемые правила в списке Rule settings for Managed Code Analysis.

Дважды щелкните OK.

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

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

Обязательное добавление пользователями комментариев при возврате.

Перед возвращением кода пользователи должны проводить дополнительные тесты.

Пользователи не используют определенные директивы C#, чтобы подавить предупреждения документации XML.

Проекты настроены так, чтобы во время компиляции генерировалась XML -документация.

Чтобы создать надстройки пользовательских политик, которые будут отображаться в диалоговом окне Add Checkin Policy, используйте функции расширяемости из комплекта Visual Studio Team Foundation Server Software Development Kit (SDK) .

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

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

С примером кода, заставляющего добавлять комментарии при возврате после правки, можно ознакомиться в статье "Sample Checkin Policy: Make Sure the Comment Isn't Empty" по адресу http://blogs.msdn.com/jmanning/ archive/2006/01/21/515858.aspx.

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

Как перекрыть политику возврата после правки

Чтобы перекрыть политику возврата после правки, задайте параметр Override policy failure and continue check-in в диалоговом окне Policy Failure. Перекрыть политику возврата после правки волен любой пользователь, обладающий разрешением на возврат файлов.

Чтобы проследить за перекрытием политики возврата после правки, воспользуйтесь службой событий Team Foundation Eventing Service.

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

Дополнительную информацию о перекрытии политики возврата после правки вы найдете в статье "How to: Override a Check-in Policy" по адресу http://msdn2.microsoft.com/en-us/library/ms245460(VS.80).aspx.

Дополнительную информацию о службе .

О том, как обнаружить перекрытие политики с помощью объектной модели .

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

Для отмены возврата файла используется команда rollback из комплекта Team Foundation Power Tools. Эта команда возвращает файл к его предыдущей версии. Команда rollback позволяет выполнить откат сразу всего набора изменений, но можно также выбирать для отката лишь некоторые файлы из набора. Это очень удобно, когда нужно отменить ошибочно возвращенное изменение файла или возвращенные изменения привели к серьезным конфликтам сборки.

Отмена возврата файла

Запустите приведенную ниже команду в окне командной строки. Переменная PATH должна включать путь \Program Files\Microsoft Team Founda-tion Server Power Tools.

TFPT rollback filename.cs

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

TFPT rollback filename.cs /changeset:54

Команда rollback запросит подтверждение на обновление рабочей области. Щелкните кнопку Yes в информационном окне Roll Back Changeset. После этого в рабочую область будут переданы файлы с сервера.

Если вы не указали номер набора изменений в командной строке, откроется диалоговое окно Find Changeset. Введите критерий поиска или просто щелкните кнопку Find. Найдите и выделите набор изменений, содержащий правку, которую вы хотите отменить, и щелкните Roll Back. Откроется окно Roll Back Changeset.

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

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

Отменяя возврат после правки командой TFPT rollback, учитывайте следующие соображения:

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

Незавершенные изменения Нельзя откатить набор, содержащий незавершенные изменения. При попытке сделать это вы получите сообщение об ошибке. Перед запуском команды rollback отложите ( shelve ) незавершенные изменения, которые хотите сохранить, а остальные отмените или запишите на сервер.

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

Разрешение конфликтов Если в процессе слияния возник конфликт, на экране появится специальное окно. Чтобы все-таки выполнить слияние, выделите элемент и щелкните кнопку Merge. Первоначально предпринимается попытка автоматического слияния. В случае неудачи для разрешения конфликта вызывается инструмент слияния. Если вы щелкнете кнопку Auto-Merge All, будет произведена попытка выполнить автоматическое слияние всех элементов, находящихся в списке слияния. Инструмент слияний не вызывается.

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

Загрузить инструмент .

Дополнительную информацию об инструменте .

Как создать пользовательскую политику возврата после правки

Для создания пользовательской политики возврата после правки используется модель надстройки, предоставленная средой политики ( policy framework ).

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

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

Надстройка политики должна предоставлять следующие интерфейсы:

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

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

Вы можете упаковать несколько надстроек политик в один файл сборки. Единственное требование - реализовать надстройки как отдельные классы.

Примечание Данные интерфейсы отображены в классе PolicyBase. В качестве альтернативы применению интерфейсов IPolicyDefinition и IPolicyEvaluation вы можете использовать производный класс из PolicyBase.

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

Дополнительную информацию о создании новой политики вы найдете в статье "Policy Plug-ins" по адресу http://msdn2.microsoft.com/en-us/ library/bb130343(VS.80).aspx.

Отладка, извлечение и блокировка

Как синхронизировать компьютер с TFS.

Как подготовить файл к редактированию.

Как синхронизировать компьютер с TFS

Для синхронизации компьютера с сервером управления версиями используется команда tf get. С ее помощью вы легко синхронизируете свою работу с остальными разработчиками и всегда будете иметь дело с новейшими версиями файлов. Чтобы загрузить все файлы, а не только обновленные, запустите в окне командной строки Visual Studio 2005 следующую команду: tf get /all

При запуске этой команды перезапись всех записываемых локальных файлов, имеющихся на вашем компьютере, не производится. Если вы хотите перезаписать локальные записываемые файлы для полной синхронизации вашего компьютера с сервером, используйте ключ /force, как показано в примере: tf get /force

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

Чтобы провести синхронизацию из Visual Studio, выполните следующие действия:

В окне Team Explorer дважды щелкните папку Source Control, правой кнопкой щелкните сервер или командный проект и выберите команду Get Specific Version.

Задайте параметры Overwrite writable files that are not checked out и Force get of file versions already in workspace.

Убедитесь, что в раскрывающемся списке Type выбран вариант Latest Version и щелкните кнопку Get.

Чтобы полностью синхронизировать компьютер с сервером управления версиями, не задавайте в Visual Studio параметр Get Latest Version. Эта команда загружает только те файлы, которых нет в вашей рабочей области, и не перезаписывает записываемые файлы, извлеченные в локальную папку. Таким образом, синхронизация компьютера с сервером фактически не выполняется.

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

Дополнительную информацию о команде .

Как подготовить файл к редактированию

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

Подготовка файла для редактирования

В окне Source Control Explorer выберите файл, щелкните его правой кнопкой мыши и выберите команду Get Latest Version. Это приведет к загрузке последней версии файла в рабочую область на вашем компьютере. Пока она будет доступна только для чтения.

Щелкните файл правой кнопкой и выберите команду Check Out for Edit.

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

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

Примечание Не путайте получение последней версии файла ( Get Latest Version ) и его извлечение для редактирования ( Check Out for Edit ). Это разные операции, и они должны выполняться отдельно. В этом TFS отличается от Microsoft Visual SourceSafe.

Выбирая тип блокировки, учитывайте следующие соображения:

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

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

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

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

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

Дополнительную информацию о команде checkout вы найдете в статье "Checkout and Edit Commands" по адресу http://msdn2.microsoft.com/pt-br/library/1yft8zkw(VS.80).aspx.

Совместное использование кода

Как организовать общий доступ к коду.

Как управлять общими двоичными файлами.

Как организовать общий доступ к коду

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

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

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

выполнить ветвление общего кода.

Установка ссылки на код из общего расположения

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

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

c:\TestProject\Client

c:\TestProject\Shared Code

В обоих проектах имеются сопоставления с этими локальными путями.


Папка системы управления исходным кодом	Локальная папка
`$/Client`	`c:\TestProject\Client`
`$/Shared Code`	`c:\TestProject\Shared Code`

Дополнительную информацию вы найдете в статье "Working with multiple team projects in Team Build" по адресу http://blogs.msdn.com/manishagar-wal/archive/2005/12/22/506635.aspx.

Ветвление общего кода

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

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

Допустим, у вас есть два командных проекта - Client и Shared Code. В проекте Shared Code расположен общий исходный код. Для ветвления кода из общего расположения выполните следующие действия:

В окне Source Control щелкните правой кнопкой корневую папку проекта Shared Code.

Выберите команду Branch.

В диалоговом окне Branch укажите в поле Target корневую папку командного проекта Client. Щелкните OK.

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

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

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

Как управлять общими двоичными файлами

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

Существуют следующие варианты хранения общих двоичных файлов:

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

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

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

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

Ветвление общих двоичных файлов в проект

В окне Source Control правой кнопкой щелкните корневую папку проекта с общими двоичными файлами.

Выберите команду Branch.

В диалоговом окне Branch укажите в поле Target корневую папку клиентского командного проекта. Щелкните OK.

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

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

Main.

Source - код проекта.

Lib - общие двоичные файлы.

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

Зависимости

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

Как управлять зависимостями БД.

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

Как правило, URL веб-службы в рабочей среде отличается от ее URL в средах разработки и тестирования. Чтобы облегчить управление веб-службами, значение URL нужно указывать в пользовательском файле конфигурации, который может изменяться отдельными разработчиками и тестировщика-ми, не затрагивая главный конфигурационный файл App.config. Для этого следует присвоить свойству URL Behavior ссылки на веб-службу значение Dynamic. Ссылайтесь на URL веб-службы при помощи пользовательского файла конфигурации.

По умолчанию при добавлении веб-ссылки Visual Studio присваивает указанному свойству значение Dynamic.

Проверка значения свойства URL Behavior

В Solution Explorer разверните список веб-ссылок.

Выделите все веб-ссылки в списке.

Убедитесь, что свойству URL Behavior каждой ссылки присвоено значение Dynamic.

Указание URL веб-службы в пользовательском файле конфигурации

При первом добавлении веб-ссылки файл App.config выглядит примерно так:

<configuration> 
  <configSections>
<sectionGroup name="applicationSettings" type="System.Configuration. 
   ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, 
      PublicK eyToken=b77a5c561934e089" >
<section name=" SomeService.Properties.Settings"
    type="System. Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, 
    PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup> 
 </configSections> <applicationSettings>
    <YourProject.Properties.Settings>
    <setting name="SomeService_ localhost _Service" serializeAs="String">
     <value>http://localhost/someservice/Service.asmx</value> </setting> </  
       YourProject.Properties.Settings> 
  </applicationSettings> 
</configuration>

В этом файле есть конфигурационный новый раздел с адресом веб-службы, заданным Visual Studio при создании этого прокси.

Создание файла User.config

В окне Solution Explorer щелкните правой кнопкой проект, содержащий ссылку на веб-службу, раскройте подменю Add и выберите команду New Item.

Выделите Application Configuration File, измените имя на User.config и щелкните Add.

Скопируйте параметр <YourProject.Properties.Settings> из файла App.con-fig в файл User.config. Этот файл должен содержать только параметры, которые изменяются во время выполнения. Удалите директиву <?xml> и элемент <configuration> , если они имеются, как показано в примере:

<YourProject.Properties.Settings>
  <setting name="SomeService_localhost_Service" serializeAs="String"> 
   <value>http://localhost/someservice/Service.asmx</value>
  </setting> 
lt;/YourProject.Properties.Settings>

В окне Solution Explorer щелкните правой кнопкой файл User.config, выберите команду Properties и присвойте свойству Copy to Output Directory значение Copy if newer.

Каждый разработчик задает в файле User.config ссылку на нужный ему URL веб-службы.

Создание в файле App.config ссылки на файл User.config при доступе к URL веб-службы

В элемент <YourProject.Properties.Settings> главного файла конфигурации приложения добавьте атрибут configSource="user.config" . При достижении рабочим циклом информации, содержащейся в этом разделе, произойдет перенаправление рабочего цикла в заданный пользовательский файл конфигурации.

Удалите содержимое элемента <YourProject.Properties.Settings> . Теперь файл App.config должен выглядеть примерно так:

<?xml version="1.0" encoding="utf-8" ?> 
  <configuration> <configSections>
  <sectionGroup name="applicationSettings" type="System.
   Configuration.ApplicationSettingsGroup,   System,  Version=2.0.0.0, Culture=neutral,   
      PublicKeyToken=b77a5c561934e089" >
    <section name="SomeService.Properties.Settings" type="System. Configuration.ClientSettingsSection,   
    System,   Version=2.0.0.0, Culture=neutral,   PublicKeyToken=b77a5c561934e089"  
       requirePermission="fal se" />
   </sectionGroup> </configSections> 
  <applicationSettings>
     <YourProject.Properties.Settings configSource="user.config">  
     </YourProject.Properties.Settings> 
  </applicationSettings> 
</configuration>

В предыдущем примере элемент YourProject представляет собой имя проекта, содержащего ссылку на веб-службу Убедитесь, что элемент <SomeService.Properties.Service> в файле App.config пуст.

Учитывайте следующие соображения:

Не добавляйте пользовательский файл конфигурации в систему управления исходным кодом. Для этого при первом возврате файла сбросьте флажок User.config. Затем щелкните файл в окне Solution Explorer правой кнопкой и выберите команду Under Pending Changes, чтобы не переносить файл в систему управления исходным кодом. Теперь каждый разработчик (и тестовая команда) сможет привязаться к конкретному URL с помощью собственного файла User.config.

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

Глобальный файл User.config следует хранить в системе управления исходным кодом. В нем может содержаться либо только корневой элемент (не элемент <setting> ), либо указание на стандартное положение веб-службы. Файл User.config нужен для работы системы конфигурирования. Важно понимать, что при использовании этого механизма файл User.config обязательно должен быть в наличии. Кто-то из команды должен отвечать за правильную работу среды во время создания сборок для рабочих выпусков и для тестирования. При сборке соответствующий файл User.config должен быть извлечен из системы управления исходным кодом и скопирован в определенное расположение, чтобы система MSBuild могла его найти.

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

Дополнительную информацию вы найдете в статье "Web Projects and Source Control Integration in Visual Studio .NET" по адресу http://msdn2. microsoft.com/en-US/library/aa290068(VS.71).aspx.

Дополнительные сведения о классе .

Как управлять зависимостями БД

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

Хранение строк подключения БД в пользовательском файле конфигурации

В главном файле конфигурации приложения добавьте атрибут configSource="user.config" в элемент <connectionStrings>, как показанов примере:

>
<configuration>
  <connectionStrings configSource="user.config"/> 
</configuration>

Чтобы перекрыть главный файл конфигурации приложения, создайте файл User.config (расположенный в той же папке, что и главный файл онфигурации приложения) и добавьте в него такой же элемент <connectionStrings> . Обратите внимание, что приведенная ниже строка подключения ссылается на локальную базу данных.

<configuration>
  <connectionStrings>
  <add name="DBConnStr" connectionString="server=localhost;
    Integrate d Security=SSPI;database=Accounts"/>
  </connectionStrings> 
  </configuration>

В проекте для получения строки подключения из пользовательского айла конфигурации используйте код, в котором используется свойство onnectionStrings класса System.Configuration.ConfigurationManager. приложении Win Form вы должны явно добавить ссылку на System. Configuration.dll.

using System.Configuration;
  private string GetDBaseConnectionString()
{
   return ConfigurationManager.ConnectionStrings["DBConnStr"]. ConnectionString; 
}

Убедитесь, что файл User.config устанавливается вместе с кодом приложения. Для этого в окне Solution Explorer щелкните правой кнопкой мыши файл User.config, выберите команду Properties и присвойте свойству Copy to Output Directory значение Copy if newer.

Не добавляйте пользовательский файл конфигурации в систему управления исходным кодом. При этом каждый разработчик (и тестовая команда) сможет задавать строку подключения с помощью собственного файла User.config. Система управления исходным кодом может содержать файлы User.config, например, для тестирования или производства. Этими файлами должны распоряжаться пользователи, ответственные за управление соответствующими средами. Такие файлы User.config, используемые при испытаниях и в производстве, не должны храниться в составе проектов БД - они должны находиться в других областях системы управления исходным кодом. Файл User.config нужен для работы системы конфигурирования.

Совет По умолчанию во время добавления решения файл User.config автоматически добавляется в систему управления исходным кодом. Чтобы избежать этого, при первом возврате файлов после правки сбросьте флажок User.config. Чтобы гарантировать непопадание этого файла в систему управления исходным кодом, щелкните его правой кнопкой в окне Solution Explorer и выберите команду Under Pending Changes.

Важно понимать, что при использовании этого механизма файл User. config обязательно должен быть в наличии. Кто-то из команды должен отвечать за правильную работу среды во время создания сборок для рабочих выпусков и для тестирования. При сборке соответствующий файл User.config должен быть извлечен из системы управления исходным кодом и скопирован в определенное расположение, чтобы система MSBuild могла его найти.

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

Дополнительную информацию об использовании файла конфигурации для определения источника данных вы найдете в статье "Walkthrough: Using a Configuration File to Define a Data Source" по адресу http://msdn2. microsoft.com/en-us/library/ms243192(VS.80).aspx.

Дополнительную информацию об атрибуте

Распределенная и удаленная разработка

Как получить доступ к TFS через Интернет.

Как повысить производительность TFS -прокси.

Как получить доступ к TFS через Интернет

Доступ к TFS через Интернет можно организовать одним из трех способов:

подключение по виртуальной частной сети ( VPN );

публикация TFS через обратный прокси, например, Microsoft Internet Security and Acceleration (ISA) ;

Расположение TFS в экстрасети.

Используйте первый способ, если вы и так обеспечиваете поддержку удаленных пользователей при помощи VPN. Он относительно прост в реализации, обладает понятной системой безопасности, обеспечивает удаленный доступ ко всем функциям TFS и позволяет использовать для повышения производительности TFS Proxy При таком способе доступа TFS находится во внутренней сети, а внешние пользователи получают к нему доступ по VPN. Внутренние пользователи обладают прямым доступом к TFS.

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

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

Если у вас есть удаленный офис с несколькими клиентами, осуществляющими доступ к Team Foundation Server через Интернет, установите в удаленном офисе Team Foundation Server Proxy. Это увеличит производительность за счет кеширования файлов исходного кода на прокси-сервере. Если вы поддерживаете одного клиента, удаленно подключающегося к TFS, настройте его на подключение непосредственно к TFS.

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

Дополнительные сведения о сценариях удаленного доступа к TFS содержатся в лекции 17 этого курса.

Дополнительную информацию о .

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

Установите и настройте Team Foundation Server Proxy в удаленном офисе. Это позволит повысить производительность за счет кеширования файлов системы управления исходным кодом на прокси-сервере.

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

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

Примечание Прокси TFS сохраняет статистику производительности кеша в XML -файле ProxyStatistics.xml. Вы можете изменить интервал, с которым происходит сохранение статистики. Файл ProxyStatistics.xml расположен в подпапке App_Data папки установки прокси.

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

Если вы заранее знаете о готовящейся передаче больших файлов по медленной сети (< 3 Мбит/с), присвойте соответствующее значение параметру executionTimeout в файле Web.config. Значение по умолчанию равно одному часу - <httpRuntime executionTimeout="3600"/> .

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

Дополнительные сведения о сценариях удаленного доступа к TFS содержатся в лекции17 этого курса.

Дополнительную информацию о .

Дополнительную информацию о тестировании производительности прокси-сервера .

Дополнительные сведения о .

Миграция

Как осуществить перенос исходного кода с Visual SourceSafe.

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

Как осуществить перенос исходного кода из Visual SourceSafe

Для переноса исходного кода из VSS выполните следующие действия.

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

Подготовка VSS. Приготовьтесь к переходу, создав резервные копии базы данных VSS и убедившись в том, что файлы возвращены в систему. Запустите инструмент Visual SourceSafe Analyze для выявления и разрешения конфликтов целостности данных в существующей БД.

Анализ проектов. Запустите конвертер (инструмент командной строки VSSConverter.exe ), передав ему с ключом analyze имя XML -файла, содержащего необходимые параметры, как показано в примере:

VSSConverter analyze conversionsettings.xml

Пример XML -файла параметров:

<?xml version="1.0" encoding="utf-8"?> 
  <SourceControlConverter>
  <ConverterSpecificSetting> <Source name="VSS">
     <VSSDatabase name="c:\VSSDatabase"></VSSDatabase> 
   </Source> <ProjectMap>
   <Project Source="$/MyFirstProject">
     </Project> <Project Source="$/MySecondProject"></Project>   
   </ProjectMap> </ConverterSpecificSetting> 
 </SourceControlConverter>

Файл параметров содержит имя БД VSS. В атрибуте name задается имя папки, содержащей .ini -файл хранилища исходного кода. Элементы <Project> определяют пути к проектам в БД VSS, которые вы собираетесь преобразовать. Для миграции всей БД VSS введите <Project Source="$/"></Project> .

Команда analize инструмента VssConverter.exe создает файл usermap.xml. Добавив сопоставления в этот файл, вы можете изменить имена, связанные с историей версий и другие, с регистрационных имен VSS на регистрационные имена TFS Windows.

Перемещение проектов. Выберите папки, которые хотите перенести, и запустите инструмент VSSConverter.exe с аргументом migrate, как показано в примере:

VSSConverter migrate conversionsettings.xml

Вы снова передаете команде XML -файл параметров настройки, но на этот раз с двумя важными дополнениями:

<?xml version="1.0" encoding="utf-8"?> 
  <SourceControlConverter> <ConverterSpecificSetting> 
    <Source name="VSS">
<VSSDatabase name="c:\VSSDatabase">
  </VSSDatabase> </Source> <ProjectMap>
   <Project Source="$/MyFirstProject" 
     Destination="$/MyTeam_ ProjectOne"></Project>
   <Project Source="$/MySecondProject" 
  Destination="$/MyTeam_ ProjectTwo"></Project> </ProjectMap>   
  </ConverterSpecificSetting> 
  <Settings>
  <TeamFoundationServer name="YourTFSServerName"
   port="PortNumber" protocol="http">
  </TeamFoundationServer>
 </Settings> 
</SourceControlConverter>

Обратите внимание на дополнительный атрибут Destination в элементах <Project> . Значение этого атрибута указывает на командный проект TFS (созданный вами заранее). Элемент <Settings> содержит подробности подключения уровня приложений TFS.

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

Дополнительную информацию о подготовке к миграции вы найдете в статье "Walkthrough: Preparing to Migrate from Visual SourceSafe to Team Foundation" по адресу http://msdn2.microsoft.com/en-us/library/ms181246 (en-us,vs.80).aspx.

Дополнительную информацию о миграции вы найдете в статье "Walkthrough: Migrating from Visual SourceSafe to Team Foundation" по адресу http://msdn2.microsoft.com/en-us/library/ms181247(VS.80).aspx.

Дополнительную информацию об ограничениях конвертера .

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

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

В настоящий момент корпорация Microsoft ведет работу по созданию конвертера ClearCase. О выпуске конвертера будет объявлено дополнительно в блоге TFS Migration по адресу http://blogs.msdn.com/tfs_migration. Существует также конвертер, созданный компанией Component Software, совместимый с GNU RCS, CS-RCS, GNU CVS, Subversion (SVN) и Visual SourceSafe (VSS) .

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

Загрузить набор инструментов .

Дополнительную информацию о расширяемости системы .

Дополнительную информацию о конвертере компании .

Управление проектом и рабочей областью

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

Как организовать дерево исходного кода.

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

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

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

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

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

Основные вопросы, которые вам предстоит ответить, таковы:

Хотите ли вы от выпуска к выпуску сохранять рабочие элементы и дру ие ресурсы? Если да, храните все выпуски в одном проекте.

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

Далее описаны типичные структуры проектов.

Один проект на все приложение

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

Почему следует использовать эту структуру?

Она упрощает перенос кода, рабочих элементов и прочих ресурсов.

Почему не следует использовать эту структуру?

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

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

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

По мере роста количества выпусков у вас накапливается солидный "багаж". Лучший способ избавиться от него - создать новый проект и перенести в него нужный вам в будущем код.

Один проект на один выпуск

Создается новый проект для каждой версии вашего приложения.

Почему следует использовать эту структуру?

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

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

Легко перемещать исходный код из одного проекта в другой.

Почему не следует использовать эту структуру?

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

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

Выбирая стратегию, имейте в виду следующее:

Выбирая структуру, думайте о дне завтрашнем: реструктуризация существующих командных проектов - трудное занятие.

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

ветвлением исходного кода из одного проекта в другой;

сопоставлением исходного кода из другого проекта в вашу рабочую область.

Система Team Foundation Server способна вместить около 500 проектов icrosoft Solution Framework (MSF) , основанных на шаблоне процесса gile Software Development (MSF Agile) , или 250 проектов на шаблоне процесса MSF CMMI. Создавая собственный процесс или настраивая существующий, помните, что на масштабируемость сервера оказывает огромное влияние схема рабочего элемента. Чем сложнее схема, там меньше проектов сможет поддерживать сервер.

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

Дополнительную информацию о стратегии выбора проекта вы найдете в логе Эрика Ли (Eric Lee) "When to use Team Projects" по адресу http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx.

Как организовать дерево исходного кода

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

Main - контейнер для всех объектов, необходимых для передачи проекта аказчику.

Source - контейнер для всех объектов, необходимых для выполнения борки.

Code - контейнер для исходного кода.

Shared Code - контейнер для исходного кода, используемого совместно с другими проектами.

Unit Tests - контейнер для модульных тестов.

Lib - контейнер для двоичных зависимостей.

Docs - контейнер для документации, поставляющейся с проектом.

Installer - контейнер для исходного кода и двоичных файлов программы установки.

Tests - контейнер, содержащий результаты испытаний, проводимых тестовой командой.

При ветвлении папки Main структура папок и файлов будет скопирована в новую ветвь, например:

Development - ветвь разработки.

Source - контейнер для всех объектов, необходимых для выполнения борки.

Code - контейнер для исходного кода.

Shared Code - контейнер для исходного кода, используемого совместно с другими проектами.

Unit Tests - контейнер для модульных тестов.

Lib - контейнер для двоичных зависимостей.

Main - ветвь интеграции.

Source - контейнер для всех объектов, необходимых для выполнения борки.

Code - контейнер для исходного кода.

Shared Code - контейнер для исходного кода, используемого совместно с другими проектами.

Unit Tests - контейнер для модульных тестов.

Lib - контейнер для двоичных зависимостей.

Docs - контейнер для документации, поставляющейся с проектом.

Installer - контейнер для исходного кода и двоичных файлов программы установки.

Tests - контейнер, содержащий результаты испытаний, проводимых тестовой командой.

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

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

Создание сопоставления рабочей области для проекта, которого еще нет на жестком диске

В окне Source Control Explorer выделите корневую папку исходного кода.

Щелкните ее правой кнопкой и выберите команду Get Latest Version.

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

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

Выберите в меню File команды Source Control и Workspaces.

В диалоговом окне Manage Workspaces добавьте, удалите или отредактируйте существующую рабочую область.

Просмотр существующего сопоставления рабочей области

В окне Source Control Explorer выделите папку с исходным кодом.

Щелкните ее правой кнопкой и выберите команду Properties. В разделе Local Name будет отображено сопоставление рабочей области на локальном диске.

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

Сопоставляйте рабочие области на корневом уровне командного проекта В новых командных проектах сопоставляйте корень проекта ( $/ MyTeamProject ) с папкой на локальном диске, имеющей то же имя, например, C:\TeamProjects. Вся структура локальной папки создается автоматически и будет в точности повторять структуру в системе управления исходным кодом.

Используйте уникальный путь к локальной папке на совместно используемых компьютерах Два пользователя одного и того же компьютера не могут использовать одно сопоставление рабочей области. Допустим, вы и ваш коллега не можете сопоставить один командный проект ( $/MyTeam-Project ) с одной и той же папкой на локальном компьютере. Создавайте сопоставления в папке Мои документы (хотя это удлиняет путь) или разработайте соглашение об именах для папок на локальном компьютере (например, C:\TeamProjects\User1, C:\TeampProjects\User2 и т. д.).

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

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

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

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

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

Разработчик волен создать две рабочие области: одна из них содержит ссылки на файлы и папки, над которыми работает остальная команда, а вторая - файлы и папки, которые он хочет изолировать. Изолирование может понадобиться, если вы хотите работать с файлами, которые параллельно изменяются где-то еще. Например, им можно пользоваться для работы над рискованными изменениями или при выполнении обзора кода.

Создание второй рабочей области

В окне Source Control Explorer щелкните раскрывающийся список Workpace и выберите команду Workspaces.

В диалоговом окне Manage Workspaces щелкните кнопку Add.

В диалоговом окне Add Workspace введите имя новой рабочей области, например, ИзолированнаяРабота. Добавьте комментарий, напоминающий о цели создания рабочей области.

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

Щелкните OK и Close, чтобы создать изолированную рабочую область.

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

В окне Source Control Explorer убедитесь, что в раскрывающееся списке Workspace выбрано имя изолированной рабочей области.

Выберите корневую папку командного проекта (или вложенную папку, если нужна только часть дерева исходного кода), щелкните ее правой кнопкой и выберите команду Get Latest Version.

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

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

Безопасность

Как защитить канал между рабочей станцией разработчика и TFS.

Как защитить канал между рабочей станцией разработчика и TFS

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

HTTPS и SSL шифруют сетевой трафик между TFS и клиентами Team Foundation, которым необходим доступ к веб-ресурсам Team Foundation Server, включая порталы проектов, отчеты и рабочие элементы.

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

Дополнительную информацию вы найдете в статье "Securing Team Foundation Server with HTTPS and Secure Sockets Layer (SSL)" по адресу http://msdn2.microsoft.com/en-us/library/aa395265(VS.80).aspx.

Дополнительную информацию о том, как установить протокол .

Дополнительную информацию о настройке .

Отложенные правки

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

Как с помощью отложенных правок передать код другому члену команды.

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

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

Выгрузка отложенных правок на сервер

Просмотрите незавершенные изменения: в Solution Explorer щелкните правой кнопкой решение и выберите команду View Pending Changes.

Выберите файлы, которые хотите выгрузить на сервер, и щелкните Shelve.

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

Восстановление работы

В меню File раскройте подменю Source Control и выберите команду Unshelve ).

Выберите нужный набор изменений и щелкните Unshelve.

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

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

Дополнительную информацию о резервном копировании незавершенных изменений вы найдете в статье "How to: Shelve and Unshelve Pending Changes" по адресу http://msdn2.microsoft.com/en-us/library/ms181404(VS.80). aspx.

Как с помощью отложенных правок передать код другому члену команды

Чтобы отложить редакцию исходного кода для передачи другому члену команды, выполните операцию Get Latest, синхронизовав свою рабочую область с последней версией на сервере. Затем произведите сборку приложения, чтобы убедиться в его компилируемости. Выгрузите исходный код в качестве отложенной правки при помощи обозревателя Source Control. Члену команды, которому предназначается код, остается только загрузить его с помощью команды Unshelve.

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

Выгрузка набора отложенных правок

Щелкните правой кнопкой окно Source Control Explorer и выберите команду Shelve Pending Changes.

В диалоговом окне Shelve - Source Files в поле Shelve name введите имя набора отложенных правок, например, shelvetest.

В поле Comment введите комментарий и щелкните Shelve.

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

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

Извлечение набора отложенных правок

В меню File Visual Studio 200 5 раскройте подменю Source Control и выберите команду Unshelve.

В поле Owner name введите имя создателя набора отложенных правок (например, ADVENTUREWORKS\JuanGo или просто juango ) и щелкните Find.

В панели Results выделите набор отложенных правок, который хотите извлечь в свою рабочую область, и щелкните Details.

Если вы хотите удалить набор отложенных правок с сервера управления исходным кодом TFS, сбросьте флажок Preserve shelveset on server.

При необходимости сбросьте флажок Restore work items and check-in notes, если не хотите вместе с набором правок восстанавливать рабочие элементы и заметки о возврате после правки.

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

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

Дополнительные ресурсы по управлению исходным кодом

Дополнительную информацию о системе управления исходным кодом .

Страницы:

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

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

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

Как защитить сервер сборки.

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

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

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

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

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

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

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

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

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

Как определить интервал выполнения скользящей сборки.

Настройка

Как изменить номер сборки.

Как настроить сопоставление рабочей области для извлечения и сборки части дерева исходного кода.

Как выполнять сборку проекта, зависящего от другого командного проекта.

Как изменить конфигурацию сборки ( release/debug ).

Развертывание

Как установить сервер сборки.

Как определить, есть ли необходимость в нескольких серверах сборки.

Общие вопросы

Как с помощью Team Build выполнять сборку и развертывание приложений ASP.NET.

Как с помощью Team Build выполнять сборку приложений на основе Microsoft® .NET 1.1.

Как с помощью Team Build выполнять сборку проектов пакетов установки и развертывания.

Как создать тип сборки.

Как создать несколько типов сборки.

Как создать сценарий сборки для проекта, в котором используются сборки из другого проекта.

Как подписаться на получение уведомлений о сборке по электронной почте.

Как получать уведомления о сбое при выполнении сборки.

Как запустить сборку.

Как убедиться, что сборка была выполнена успешно.

Как просмотреть результат сборки.

Как изменить расположение сервера сборки.

Как изменить место накопления результатов сборки.

Как определить, какие наборы изменений являются частью сборки.

Как изменить заявленное качество сборки.

Проекты

Как применять стратегию с одиночным решением.

Как применять стратегию с разделенным решением.

Как применять стратегию с несколькими решениями.

Отчеты

Как просмотреть информацию о качестве сборки.

Как просмотреть возвраты изменений для конкретной сборки.

Как просмотреть закрытые рабочие элементы или ошибки, связанные со сборкой.

Как просмотреть открытые рабочие элементы или ошибки, связанные со сборкой.

Как отследить изменение скорости выполнения проекта от сборки к сборке.

Как отслеживать пройденные и непройденные тесты для сборки.

Как просмотреть состояние сборки.

Плановые сборки

Как настроить автоматический запуск сборки по ночам.

Как выбрать для проекта частоту выполнения сборки и ее тип.

Разработка через тестирование

Как создать простейший приемочный тест.

Как выполнять автоматизированное тестирование в ходе сборки.

Как выполнять анализ кода в ходе сборки.

Как реализовать сбой сборки при непрохождении тестов.

Администрирование

Как защитить сервер сборки.

Как удалить сборку.

Как удалить тип сборки.

Как связать со сборкой рабочий элемент.

Как защитить сервер сборки

Обеспечение безопасности сервера сборки

Дополнительные ресурсы

Подробную информацию о группах .

Как удалить сборку

Для удаления сборок используется инструмент командной строки myproject build20070606.4

Дополнительные ресурсы

Как удалить тип сборки

Удаление типа сборки

Откройте Source Control Explorer.

Разверните папку своего командного проекта.

Разверните папку TeamBuildTypes.

Еще раз щелкните правой кнопкой мыши папку Team Build и выберите Check In Pending Changes.

Откройте Team Explorer.

Щелкните правой кнопкой мыши папку Team Builds и выберите Refresh.

Разверните папку Team Builds и убедитесь, что тип сборки удален.

Дополнительные ресурсы

Более подробно о .

Как связать со сборкой рабочий элемент

Связывание рабочего элемента со сборкой

Внесите в код изменения, которые хотите включить в сборку и связать с рабочим элементом.

Верните ожидающие изменения в систему управления исходным кодом.

В диалоговом окне Check In щелкните Work Items.

Дополнительные ресурсы

Политики возврата после правки

Как с помощью политик возврата повысить качество возвращаемых изменений.

Как связать рабочие элементы со сборкой при помощи политики возврата изменений.

Как с помощью политик возврата повысить качество возвращаемых изменений

Включение политики анализа кода при возврате изменений

В Team Explorer щелкните правой кнопкой мыши свой командный проект, выберите Team Project Settings и щелкните Source Control.

Перейдите на вкладку Check-in Policy.

Щелкните Add. Затем выберите и настройте политики анализа кода и тестирования.

Дополнительные ресурсы

Как связать рабочие элементы со сборкой при помощи политики возврата изменений

Включение политики связи возврата изменений с рабочими элементами

В Team Explorer щелкните правой кнопкой мыши свой командный проект, выберите Team Project Settings и щелкните Source Control.

Перейдите на вкладку Check-in Policy.

Щелкните Add. Выберите и настройте политику возврата Work Item.

Дополнительные ресурсы

Непрерывная интеграция

Как автоматически запускать сборки непрерывной интеграции.

Как определить, нужна ли скользящая сборка.

Как определить интервал выполнения скользящей сборки.

Как автоматически запускать сборки непрерывной интеграции

Создание решения непрерывной интеграции

Создайте и протестируйте сборку Убедитесь, что у вас есть нужный тип сборки и что он выполняется без ошибок.

<add key="1" value="TeamServer=http://TFSRTM:8080;
  TeamProjectName=Advent ureWorks;BuildType=Test Build"/>

Bissubscribe /eventType CheckinEvent /address 
  http://TFSRTM:8080/ci/no-tify.asmx /deliveryType Soap /domain http://TFSRTM:8080

Подробнее - в разделе "Как настроить непрерывную интеграцию в Visual Studio Team Foundation Server " этого курса.

Дополнительные ресурсы

Более подробную информацию вы найдете в лекции8 этого курса.

Дополнительную информацию об использовании непрерывной интеграции в .

Скачать .

Подробнее о гибкой разработке и непрерывной интеграции в .

Как определить, нужна ли скользящая сборка

продолжительность сборки Team Build в минутах;

средний интервал между последовательными возвратами после правки в минутах;

промежуток времени, в течение которого возвраты после правки производятся наиболее часто.

Дополнительные ресурсы

Дополнительную информацию вы найдете в лекции8 этого курса.

Как определить интервал выполнения скользящей сборки

Дополнительные ресурсы

Дополнительную информацию вы найдете в лекции8 этого курса.

Настройка

Как изменить номер сборки.

Как настроить сопоставление рабочей области для извлечения и сборки части дерева исходного кода.

Как выполнять сборку проекта, зависящего от другого командного проекта.

Как изменить конфигурацию сборки ( release/debug ).

Как изменить номер сборки

Настройка номера сборки в файле сборке и в интерфейсе Team Build

Переопределите $(BuildNumber) в цели BuildNumberOverride.

Переопределите цель 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>

Дополнительные ресурсы

Еще один метод изменения версии сборки предлагается в блоге Аарона Холберга ( .

Задаче .

Подробнее о настройке .

Как настроить сопоставление рабочей области для извлечения и сборки части дерева исходного кода

Сокрытие папки

Извлеките для правки файл WorkspaceMapping.xml.

Добавьте в файл записи о сокрытии.

<Mappings>
<InternalMapping ServerItem="$/MyTeamProject" LocalItem="c:\projects\ teamproject" Type="Map" />
<InternalMapping ServerItem="$/MyTeamProject/documentation" Type="Cloak" /> </Mappings>

Дополнительные ресурсы

Дополнительную информацию о схеме .

Как выполнять сборку проекта, зависящего от другого командного проекта

Сборка проекта, зависящего от другого командного проекта

В Source Control Explorer извлеките для редактирования сценарий TFSBuild.proj.

В разделе PropertyGroup (группа свойств) добавьте следующие параметры:

<!-- должны находиться под PropertyGroup -->
<TfCommand>$(TeamBuildRefPath)\..\tf.exe</TfCommand>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>

<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>

Переопределите событие 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>

Верните изменения сценария в систему управления исходным кодом и выполните сборку.

Дополнительные ресурсы

Как изменить конфигурацию сборки (release/debug)

Изменение конфигурации сборки

Откройте Source Control Explorer.

Разверните папку своего командного проекта.

Разверните папку TeamBuildTypes.

Выберите папку сценария сборки, для которого хотите включить анализ кода.

Чтобы открыть TFSBuild.Proj, в окне Source Control Explorer щелкните его дважды.

Измените конфигурацию сборки в теге <ConfigurationToBuild> .

Сохраните TFSBuild.proj и верните его в систему управления версиями .

Дополнительные ресурсы

Подробнее о настройке .

Развертывание

Как установить сервер сборки.

Как определить, есть ли необходимость в нескольких серверах сборки.

Как установить сервер сборки

Установка сервера сборки

Установите Visual Studio.

В папке на DVD -диске Team Foundation Server откройте папку uild.

Запустите мастер установки.

Учетная запись, используемая для запуска сервера сборки, должна обладать следующими свойствами:

должна обладать разрешением 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

Запустите New Team Build Type Creation Wizard.

Задайте имя типа сборки.

Выберите решение, содержащее только веб-приложение ASP.NET

Выберите соответствующую конфигурацию.

В раскрывающемся списке Platform выберите платформу .NET

Задайте расположение типа сборки.

Выберите тесты и правила анализа кода.

Сохраните тип сборки, щелкнув Finish.

Сборка решения, содержащего веб-приложения ASP.NET и другие .NET -проекты

Запустите New Team Build Type Creation Wizard.

Задайте имя типа сборки.

Выберите решение, содержащее веб-приложения ASP.NET и другие проекты.

Выберите соответствующую конфигурацию.

В раскрывающемся списке Platform выберите вариант Mixed.

Задайте расположение типа сборки.

Выберите тесты и правила анализа кода.

Сохраните тип сборки, щелкнув Finish.

Послесборочный этап для развертывания веб-приложения

Скачайте библиотеку .

Из скачанного zip -архива извлеките файл Microsoft.Sdc.Tasks.dll и поместите его в ту же в папку, что и тип сборки.

Добавьте библиотеку DLL в систему управления исходным кодом и возвратите ее.

Добавьте элемент <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>

Сохраните файл и передайте его в хранилище системы управления исходным кодом.

Проект развертывания веб-приложения

Скачайте и установите на клиентский компьютер Visual Studio 2005 Web Deployment Projects.

Скачайте и установите на сервере сборки Visual Studio 2005 Web Deployment Projects.

Откройте решение, содержащее веб-приложение.

В меню Build выберите команду Add Web Deployment Project.

Задайте имя и расположение проекта развертывания.

В Solution Explorer правой кнопкой мыши щелкните Web Deployment Project и выберите Property Pages.

В разделе Deployment установите флажок Create an IIS virtual directory for the output folder и задайте имя виртуальной папки.

Щелкните OK.

Верните изменения в систему управления исходным кодом.

Дополнительные ресурсы

Подробнее о сборке приложений .

Более подробную информацию об использовании проектов .

Дополнительную информацию о сборке проектов .

Как с помощью Team Build выполнять сборку приложений на основе Microsoft® .NET 1.1

Сборка приложений .NET 1.1 с использованием Team Build 2005

Убедитесь, что на сервере сборки установлен .NET 1.1 Software Develop ment Kit (SDK) .

Скачайте и установите ).

Скачайте .

Скопируйте BuildingFx11inTB.targets в папку, содержащую тип сборки, и верните файл в систему управления исходным кодом.

Отредактируйте файл TFSBuild.proj:

Импортируйте файл BuildingFx11inTB.targets:

<Import Project="$(MSBuildProjectDirectory)\BuildingFx11inTB.targets" />

Добавьте свойство, определяющее цели CSharp:

<PropertyGroup> 
 <AdditionalPropertiesForBuildTarget>  
   CustomAfterMicrosoftCommonTargets=$(ProgramFiles)\MSBuild\MSBee\ MSBuildExtras.Fx1_1.CSharp.targets
  </AdditionalPropertiesForBuildTarget> 
</PropertyGroup>

Верните файл 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>

Дополнительные ресурсы

Подробнее о .

Дополнительную информацию об использовании .

Как с помощью Team Build выполнять сборку проектов пакетов установки и развертывания

Протестируйте сборку

Задайте выполнение сборки пакета установки

В Solution Explorer щелкните правой кнопкой мыши проект установки, для которого будет создаваться сценарий сборки.

Щелкните Properties.

Щелкните Configuration Manager.

Выберите необходимые конфигурации ( Debug, Release, обе).

Установите флажок Build для проекта пакета установки.

Сделайте все пути сборки в файле проекта относительными

Откройте папку решения для проекта пакета установки.

Откройте файл .vdproj в любом другом редакторе (не в Visual Studio ).

Извлеките файл .vdproj из системы управления исходным кодом для редактирования.

"OutputFileName" = "8:c:\\temp\\SetupProject.msi"

замените на

"OutputFileName" = "8:debug\\SetupProject.msi"