Руководства

Ветвление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка

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

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

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

Используйте MS Build Toolkit Extras для сборки приложений Microsoft .NET 1.1

Team Build по умолчанию не поддерживает приложения .NET 1.1. Производить сборки .NET 1.1 позволяет пакет MSBuild Extras - Toolkit for .NET 1.1 (MSBee) , но при этом потребуется обновление проектов и решений до Visual Studio 2005. Если это невозможно, используйте для компиляции приложений .NET 1.1 пользовательский послесборочный шаг. Дополнительные ресурсы

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

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

В файле TFSBuild.proj содержится множество сведений, необходимых для работы Team Build. Здесь, в частности, задается, должны ли при сборке выполняться статический анализ кода и модульные тесты. Чтобы изменить параметры сборки, отредактируйте файл TFSBuild.proj.

Редактирование файла TFSBuild.proj

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

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

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

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

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

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

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

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

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

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

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

По умолчанию перед извлечением дерева исходного кода, необходимого для сборки, Team Build очищает папку, используемую для выполнения сборки. Кроме того, Team Build удаляет и повторно инициализирует рабочую область, используемую для извлечения исходного кода. Если объем исходного кода, необходимого для сборки, достаточно велик и сервер сборки установлен отдельно от TFS -сервера, извлечение исходного кода может занять много времени. Чтобы повысить производительность, настройте Team Build так, чтобы извлекался только тот исходный код, который изменился с момента последней сборки. Для этого вам потребуется установить несколько значений в файле TFSBuild.proj:

Выполнение инкрементной сборки

<PropertyGroup>
<SkipClean>true</SkipClean>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>
<ForceGet>false</ForceGet> </ PropertyGroup>

Эти настройки приводят к следующим результатам:

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

Избегайте синхронизации излишних папок при сборке

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

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

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

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

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

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

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

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

Используйте рабочие области, чтобы запретить извлечение для правки нежелательных файлов и проектов в Team Build

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

Большой командный проект, как правило, содержит несколько решений Visual Studio, каждое из которых используется для сборки отдельных частей проекта. Создавая тип командной сборки, вы указываете решение, которое будет использоваться при сборке. Если вы зададите файл решения без указания рабочей области, перед выполнением сборки Team Build извлечет все исходные коды командного проекта.

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

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

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

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

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

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

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

Проекты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TfsBuild start <<имя сервера сборки>> << командный проект>> << тип сборки>>

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

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

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

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

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

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

<RunCodeAnalysis> на Always.

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

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

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

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

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

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

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

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

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

<OnError ExecuteTargets="CreateWorkItem;">

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

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

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

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

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

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

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

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

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

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

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

Руководство по управлению проектом

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

Области и итерации

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

Шаблоны процесса

Группы безопасности и разрешения

Командные проекты

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

Области и итерации

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

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

Области применяются для представления логических или физических компонентов, а подобласти ( sub-area ) представляют отдельные функции. Такая структура помогает упорядочить рабочие элементы и упрощает отслеживание работ по компоненту или функции.

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

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

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

Представляйте вехи проекта с помощью итераций

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

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

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

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

Создавайте отдельные итерации для неназначенных сценариев и задач

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

Создание отдельной итерации

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

Определите продолжительность цикла итерации

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

На практике в большинстве командных проектов работает двухнедельный цикл итерации.

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

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

Повышайте качество кода при помощи политики возврата после правки

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

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

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

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

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

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

Настройка политики Work Items

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

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

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

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

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

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

Система управления версиями Team Foundation Server Version Control не запрещает перекрывать политики возврата после правки. Однако вы можете выполнить следующие действия, чтобы при помощи службы Team Foundation Server Eventing Service из Team Foundation Core Services API выявить факт перекрытия политики: напишите метод Notify, проводящий разбор свойств набора изменений и реагирующий на факт перекрытия. Можно также обнаружить перекрытие политики, просмотрев историю набора изменений вручную.

Дополнительная информация

Шаблоны процесса

Используйте шаблон процесса MSF Agile в несложных проектах, допускающих неформальный подход

Используя методику разработки через тестирование ( Test-Driven Development, TDD ) или другие гибкие методики, работайте с шаблоном процесса MSF for Agile Software Development (MSF Agile) . Он представляет собой облегченный подход к гибким проектам разработки ПО. Его следует использовать, если вы не слишком нуждаетесь в дополнительных функциях усовершенствования процесса из шаблона MSF CMMI.

Шаблон процесса MSF Agile легко редактировать, изменяя его в соответствии с требованиями вашего процесса.

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

Используйте шаблон процесса MSF CMMI в проектах, требующих более формального подхода или соответствия стандартам CMMI

При использовании более формального подхода к разработке ПО, направленного на усовершенствование существующего процесса, применяйте шаблон процесса MSF для CMMI Software Development. Его также можно изменить в соответствии с требованиями вашего процесса.

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

По возможности используйте минимальный шаблон процесса

Многим командам не требуется поддержка всех разделов стандартного командного проекта. Например, многие команды довольствуются системой управления исходным кодом и не собираются использовать портал Microsoft Office SharePoint®. В подобных случаях шаблоны командных проектов можно изменять, удаляя ненужные разделы. В шаблоне всегда должны присутствовать разделы Group Permissions и Classifications, от остальных же можно смело избавляться.

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

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

Отредактируйте существующий шаблон в соответствии с потребностями вашей команды

Проект, над которым вы работаете, может не соответствовать стандартным шаблонам процесса, поставляющимся с Microsoft Visual Studio Team System (VSTS) . Вам может понадобиться другой тип рабочего элемента или иная методология процесса. В таком случае вам следует отредактировать существующий шаблон процесса. Выберите шаблон, максимально близкий к вашим требованиям, и измените его в соответствии с этими требованиями. Как правило, настройке подлежат следующие области шаблона:

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

Группы безопасности и разрешения

Создавайте группы безопасности для назначения определенного набора разрешений

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

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

Руководствуйтесь следующими соображениями:

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

Распределяйте членов команды по соответствующим группам

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

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

Командные проекты

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

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

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

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

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

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

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

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

Не увлекайтесь предоставлением разрешений на доступ к ресурсам проекта

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

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

Структурируйте дерево исходного кода с учетом ветвления

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

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

Ниже приведен пример дерева исходного кода с поддержкой ветвления: Main - контейнер, содержащий все объекты, необходимые для отправки проекта заказчику.

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

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

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

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

Создание сценариев в начале проекта

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

Правильно определяйте требования QoS

Определите требования QoS для каждого сценария, над которым будет вестись работа в цикле итерации. Это поможет определить критерий приемки сценария. Требования к QoS основываются на целях и требованиях проекта, а также на документах спецификации, если таковые имеются.

Определение требований QoS

Важно! Позже вы сможете разбить требования QoS на тестовые задачи.

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

Разделяйте сценарии на управляемые задачи

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

Разделение сценариев на управляемые задачи

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

Разрабатывайте критерии приемки для каждой задачи

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

Критерий приемки чаще всего определяется как требование к интерфейсу в виде мини-сценария или требования QoS. После успешного прохождения приемки разработчик помечает задачу как завершенную и переходит к следующей.

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

Связывайте требования и задачи со сценариями

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

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

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

Используйте Microsoft Excel для массового редактирования рабочих элементов

Система Team Foundation Server не поддерживает массового редактирования рабочих элементов. Вам приходится редактировать каждый элемент индивидуально. Если вам все-таки нужно отредактировать много рабочих элементов за короткое время, например, за время совещания, вам поможет Microsoft Office Excel®. Экспортируйте рабочие элементы из TFS в Excel, модифицируйте, а затем снова импортируйте в TFS для сохранения правок.

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

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

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

Руководство по отчетам

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

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

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

Просмотр

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

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

Если вы хотите, чтобы у пользователя была возможность разворачивать отчеты, убедитесь, что он включен в роль Content Manager сервера отчетов. Эта роль предопределена в Report Services и предназначена для пользователей, осуществляющих развертывание и управление отчетами и подключениями к источникам данных на веб-сервере. Чтобы пользователь мог разворачивать отчеты на сервере отчетов системы Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) , он должен быть членом этой роли.

Добавление пользователя в роль Content Manager

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

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

Панель отчетов позволит вам и вашей команде получить на одной странице доступ ко всей важной информации о проекте. Стандартная страница портала Microsoft Office SharePoint® шаблона Microsoft Solution Framework (MSF) для проектов MSF Agile содержит один отчет и ссылки на остальные. Чтобы создать единое хранилище для информации по проекту, измените страницу портала проектов MS Agile или MSF CMMI, чтобы она включала столько отчетов, сколько вам нужно.

Функциональная панель отчетов должна, вероятно, включать следующие отчеты:

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

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

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

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

Убедитесь в правильности имени сервера при развертывании отчетов

Если URL сервера отчетов или имя целевой папки указаны неверно, отчет не будет развернут на сервере отчетов. Выполняя развертывание отчета из Visual Studio 2005, укажите URL сервера, на который следует выполнить развертывание, и имя командного проекта, частью которого является данный отчет. Адрес URL сервера отчетов, на котором будет произведено развертывание, выглядит так: http://TeamServerName/СерверОтчетов, где СерверОтчетов - конечная точка веб-службы Report Server.

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

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

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

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

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

Создав расписание, вы сможете просматривать отчеты на вкладке History этого отчета. Там же можно создать снимок вручную.

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

Редактирование отчетов осуществляется при помощи инструмента Microsoft SQL Server™ 2005 Reporting Services Designer, входящего в Visual Studio (Business Intelligence Development Studio) из клиентского комплекта SQL Server 2005.

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

Примечание Вы, конечно, можете использовать построитель отчетов ( Report Builder ), который имеется на сайте отчетов команды, но этот инструмент не очень хорошо поддерживается сценариями отчетов Visual Studio, поэтому работать с ним не рекомендуется.

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

Просмотр

Чтобы получить актуальные данные, убедитесь в работе веб-службы хранилища

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

Ручной запуск службы хранилища

Отобразится текущее состояние веб-службы хранилища. Значение idle указывает, что запуск службы был выполнен.

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

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

Руководство по управлению исходным кодом

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

Доступ к системе управления версиями

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

Ветвление, метки, слияние

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

Получение и блокировка кода

Зависимости

Распределенная и удаленная разработка

Переход из других версий

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

Отложенные правки

Доступ к системе управления версиями

Инструменты командной строки

Для операций, не предусмотренных пользовательским интерфейсом Visual Studio, а также для задач, выполняемых по расписанию, удобны инструменты командной строки, например, Team Foundation Power Tools ( Tfpt.exe ), которые включены в комплект Team Foundation Server (TFS) , но загружаются отдельно. С их помощью вы можете настраивать выполнение задач по расписанию, используя планировщик заданий Windows (Task Scheduler) .

Чтобы с гарантией задать нужные пути и другие переменные окружения, запускайте Tf.exe из окна командной строки Visual Studio или выполните пакетный файл Vsvars32, который обычно располагается в папке Диск:\ Program Files\Microsoft Visual Studio 8\Common7\Tools. Инструмент Tf.exe поддерживает большинство команд системы управления исходным кодом, включая Checkin, Checkout, Get, History, Shelve, Branch, Merge, Label, Status, Undelete и Undo.

Ниже указаны наиболее распространенные операции, выполняемые из командной строки с помощью Tf.exe:

Извлечение определенного набора изменений с сервера: tf get /version. Некоторые операции можно выполнить только из командной строки:

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

Team Foundation Power Tools: восстановление отложенных изменений

Инструментарий Team Foundation Power Tools (TFPT) обладает функциональными возможностями, недоступными в Visual Studio. Например, он поддерживает работу в автономном режиме, позволяет отменять возвращенные правки из набора изменений, а также восстановить отложенные изменения.

Операция возврата отложенных изменений ( unshelve ), поддерживаемая TFS, не допускает слияния отложенных изменений ( shelved change ) и локальных изменений ( local change ). Если в элемент локальной рабочей области внесено незафиксированное изменение-правка и кроме того с ним связано отложенное изменение-правка, TFPT позволяет выполнить трехстороннее слияние изменений.

Эта команда запускается из командной строки при помощи Tfpt.exe.

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

Team Foundation Power Tools: откат изменения

Вообще, система TFS напрямую не позволяет отменить возврат набора изменений, но вы можете попытаться отменить любые изменения, сделанные в конкретном наборе, при помощи команды rollback. Отменить удастся не все изменения, но в большинстве сценариев команда rollback работает. Эта команда запускается из командной строки при помощи Tfpt.exe.

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

Team Foundation Power Tools: автономная работа

В целом, автономный режим в TFS не поддерживается. Чтобы работать автономно, выполните описанные ниже действия в строго заданной последовательности:

Далее приводится подробное описание каждого из этих шагов.

Важно! Во время автономной работы нельзя переименовывать файлы.

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

Team Foundation Power Tools: получение набора изменений

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

Эта команда запускается из командной строки при помощи Tfpt.exe.

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

Team Foundation Power Tools: удаление невозвращенных правок

Используйте инструмент TFPT, чтобы удалить из файлов невозвращенные правки. Команда TFPT Undo Unchanged удаляет невозвращенные правки из файлов, редактирование которых не было выполнено. Это полезно, когда вы извлекаете для редактирования большое количество файлов, но реально изменяете лишь некоторые из них. Вы можете отменить правки в неизмененных файлах, запустив инструмент TFPT UU. Он сравнивает хеши файлов в локальной рабочей области с хешами на сервере, что позволяет установить, был ли файл на самом деле изменен.

Эта команда запускается из командной строки при помощи Tfpt.exe.

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

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

Отключайте наследуемые разрешения в ветвях сопровождения

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

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

Подробнее об удалении разрешений читайте в статье "How to: Remove Access to Source Control Files" по адресу http://msdn2.microsoft.com/en-us/library/ ms400718(VS.80).aspx.

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

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

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

Подробнее об удалении разрешений читайте в статье "How to: Remove Access to Source Control Files" по адресу http://msdn2.microsoft.com/en-us/library/ ms400718(VS.80).aspx.

Ветвление, метки, слияние

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

Присваивайте метки повседневным сборкам, чтобы можно было быстро просмотреть и извлечь набор файлов, использованных в той или иной сборке. Система TeamBuild автоматически присваивает метку набору файлов, связанному с каждой создаваемой ей сборкой. Формат меток TeamBuild таков: "ТипВыпуска_НомерСборки", например, "Releasex86_20070226.1".

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

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

Чтобы найти существующую метку, откройте меню File, разверните подменю Source Control, Label и щелкните Find Label. Найдя метку, вы можете изменить или удалить ее в диалоговом окне Find Label.

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

Используйте ветвление для изоляции выпусков

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

Далее приведен пример структуры ветвей после создания ветви Maintenance для поддержки вышедших версий ПО:

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

Планируйте структуру ветвей в соответствии с путями слияний

Слияние в обозревателе Source Control возможно только по существующим путям ветвления. Из командной строки вы можете выполнять слияние без основы по другим путям, однако такой тип слияния менее гибок, что приводит к большему количеству конфликтов в текущем слиянии и будущих слияниях. Выполняя слияния, имейте в виду следующее. Слияние вдоль иерархии, от дочерней папки к родительской и наоборот, приводит к меньшему количеству конфликтов, чем слияние поперек иерархии. Кроме того, иерархия ветвей, основанная на родительских и дочерних ветвях, может отличаться от физической структуры исходного кода на диске. Например:

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

Выполняйте ветвление на высоком уровне, включая файлы конфигурации и исходного кода

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

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

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

Избегайте глубокого ветвления

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

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

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

Избегайте ветвления без необходимости

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

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

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

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

Избегайте слияния без основы

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

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

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

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

Предпочитайте полное слияние выборочному

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

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

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

Чаще выполняйте слияния

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

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

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

Всегда создавайте папку верхнего уровня для нового командного проекта

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

Далее показан пример типичной структуры ветвления:

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

Используйте перед слиянием параметры Candidate или Preview

Перед выполнением слияния используйте параметры \candidate или \pre-view, чтобы проверить результаты слияния. Хотя эта возможность доступна только из командной строки, пренебрегать ею не следует. Она позволяет узнать, слияние каких файлов и версий будет выполнено при запуске команды слияния. С ее помощью, например, можно удостовериться, что реальный масштаб слияния не превышает ваши ожидания и что вы правильно оценили все последствия предпринимаемого слияния. При выполнении больших слияний отчет о слиянии поможет вам разделить работу между разработчиками или группами.

Для предварительного просмотра результатов слияния запустите инструмент командной строки Tf.exe с командой merge и параметрами preview или candidate, например:

Tf merge main/source development/feature/source /preview

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

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

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

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

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

Соблюдайте осторожность при разрешении конфликтов слияния

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

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

Не возвращайте результаты двух и более слияний одновременно

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

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

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

Проводите тесты после слияния, но перед возвратом

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

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

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

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

Возвращайте код, только убедившись в его надежности

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

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

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

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

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

Чтобы отложить правки, сначала просмотрите их список: щелкните правой кнопкой решение в окне обозревателя Solution Explorer и выберите команду View Pending Changes. Выберите файлы, которые хотите отложить и щелкните Shelve. Введите имя набора и комментарий, поясняющий его назначение, а затем щелкните Shelve.

Извлечение набора отложенных правок

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

Разрешайте только один рабочий элемент за один возврат

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

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

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

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

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

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

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

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

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

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

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

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

Следите за перекрытием политики

Система Team Foundation Version Control не предотвратит перекрытие политики. Однако, выполнив следующие действия, вы сможете установить факт перекрытия политики:

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

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

Избегайте конфликтов при помощи планирования

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

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

Чтобы выяснить, извлек ли кто-то файл или нет, выполните следующие действия:

Чтобы узнать, для каких файлов в данный момент имеются незавершенные изменения, в командной строке Visual Studio 2005 введите следующую команду:

Tf status /format:detailed /user:*

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

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

Получение и блокировка кода

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

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

Чтобы получить последние копии файлов, относящихся к тому или иному проекту, щелкните правой кнопкой командный проект в окне обозревателя Source Control и выберите команду Get Latest Version. Если в данный момент в вашей рабочей области имеются записываемые файлы с незавершенными правками, эти файлы не будут перезаписаны. Эту команду можно запустить и из командной строки, введя Tf get /all в папке, сопоставленной с текущей рабочей областью.

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

Осмотрительно пользуйтесь командой lock

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

Ниже приведены сценарии, при которых использование команды lock оправдано:

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

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

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

В отличие Microsoft Visual Source Safe® (VSS) , при извлечении файла в TFS вам не предлагается по умолчанию последняя версия. Прежде чем заблокировать файл, поместите в рабочую область его последнюю версию, выполнив команду Get Latest Version.

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

Предупредите коллег о блокировке файла

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

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

Чтобы заблокировать файл в окне обозревателя Source Control, щелкните файл правой кнопкой мыши и выберите команду Lock. Затем укажите тип блокировки - Check Out или Check In.

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

Зависимости

Старайтесь использовать ссылки на проект

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

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

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

Без необходимости не используйте файловые ссылки

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

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

Для ссылок на проект и файл используйте параметр copy local = true

С каждой ссылкой сопоставлен атрибут copy local. В Visual Studio значение этого атрибута ( TRUE или FALSE ) задается при первом добавлении ссылки. Значение FALSE присваивается, если сборка находится в глобальном кеше сборок ( GAC ). В противном случае, присваивается значение TRUE. Значение, заданное по умолчанию, изменять не следует.

Если атрибут copy local имеет значение true, система сборки Visual Studio копирует любую сборку, на которую имеется ссылка, а также все зависимые нисходящие сборки, в клиентскую выходную папку. Например, если клиентский проект ссылается на сборку Lib1, а Lib1 зависит от Lib2 и Lib3, то во время сборки Visual Studio автоматически копирует Lib1, Lib2 и Lib3 в локальную выходную папку вашего проекта.

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

В ссылках на веб-службы используйте динамические URL

Чтобы вызвать веб-службу, следует добавить в проект веб-ссылку Так генерируется прокси-класс, посредством которого вы взаимодействуйте с веб-службой. Код прокси изначально содержит или http://SomeWebServer.

Важно! Для веб-служб, выполняющихся на вашем компьютере, всегда используйте адрес http://localhost а не http://ИмяМоегоКомпьютера, чтобы сохранить работоспособность ссылки на любом компьютере.

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

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

Распределенная и удаленная разработка

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

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

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

Создайте задание для получения последних файлов по расписанию

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

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

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

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

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

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

TFS Proxy сохраняет статистические данные о производительности кеша в XML -файле ProxyStatistics.xml. Вы вольны задать временной интервал для сохранения этих данных. Файл ProxyStatistics.xml находится в подпапке App_Data папки установки прокси.

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

Настраивайте executionTimeout соответственно размеру файла и ширине канала

Если вам предстоит загрузка больших файлов по сети с невысокой пропуск ной способностью (менее 3 Мбит/с), исправьте значение параметра executionTimeout в файле Web.config, чтобы сократить вероятность истечения срока передачи. Значение по умолчанию равно одному часу:

<httpRuntime executionTimeout="3600"/>.

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

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

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

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

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

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

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

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

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

Переход из других версий

Переходите на Team Foundation Server Source Control при помощи VSS Converter

В комплекте Team Foundation Server поставляется инструмент VSS Converter, позволяющий переносить файлы, папки, историю версий, метки и пользовательскую информацию из БД Visual SourceSafe в систему управления исходным кодом Team Foundation Server.

Следует знать, что конвертер имеет некоторые ограничения, например:

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

Переходите на Team Foundation Server Source Control из других систем управления исходным кодом

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

В данный момент корпорация .

Существует конвертер, созданный компанией Component Software, который совместим с системами GNU RCS, CS-RCS, GNU CVS, Subversion (SVN) и Visual SourceSafe (VSS) . Дополнительные ресурсы

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

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

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

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

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

Удаляйте и переименовывайте файлы в системе управления исходным кодом, а не в проводнике Windows

Если вам надо удалить или переименовать файлы, добавленные в систему управления исходным кодом, это следует делать в обозревателе Source Control, запустив Tf.exe из командной строки. Нельзя удалять и переименовывать файлы в проводнике Windows, так как при этом нарушается синхронизация файлов локальной рабочей области с файлами сервера управления исходным кодом.

Порядок действий при удалении файла или папки при помощи Source Control Explorer:

Слева появится значок, символизирующий удаление объекта. В столбце Pending Change отобразится статус Delete. Удаление произойдет при очередном возврате правок.

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

Особенно удобно использование команд Tf move, delete и rename при работе с несколькими файлами или папками одновременно. В обозревателе Source Control можно перемещать, переименовывать или удалять только по одному файлу или папке.

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

Удаляйте и переименовывайте файлы только при открытом решении

Удаление и переименование файлов в Solution Explorer следует выполнять при открытом решении. Не удаляйте их непосредственно с диска. Это гарантирует, что при следующем возврате незавершенных изменений система управления исходным кодом TFS сохранит синхронизацию.

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

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

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

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

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

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

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

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

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

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

Управление общим исходным кодом или двоичными файлами производится в два этапа:

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

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

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

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

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

Сопоставляйте рабочие области на корневом уровне командного проекта

В новом командном проекте сопоставляйте корень проекта ( $/ MyTeamProject ) с папкой на локальном диске, имеющей похожее имя, например, C:\TeamProjects. Поскольку сопоставления являются рекурсивными, вся структура локальной папки создается автоматически и будет в точности повторять структуру в системе управления исходным кодом.

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

Используйте уникальный путь к локальной папке на общих компьютерах

Два пользователя одного компьютера не могут использовать одно и то же сопоставление рабочей области. Допустим, вы и ваш коллега не можете сопоставить один командный проект ( $/MyTeamProject ) с одной и той же папкой на локальном компьютере. Создавайте сопоставления в папке Мои документы (хотя это удлиняет путь) или разработайте соглашение об именах для папок на локальном компьютере (например, C:\TeamProjects\User1, C:\ TeampProjects\User2 и т.д.).

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

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

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

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

Структурируйте дерево исходного кода с учетом ветвления

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

Любое ветвление, проводимое не в папке Main, повлечет за собой копирование структуры папок и файлов в новую ветвь, например:

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

Отложенные правки

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

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

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

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

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

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

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

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