Практикум

Как добавить нового разработчика в проект Visual Studio 2005 Team Foundation Server

Область применения

Описание

В этой статье подробно разбирается процесс введения нового разработчика в командный проект Team Foundation Server.

Содержание

Задачи

Обзор

Вводя в проект нового разработчика, необходимо предоставить ему соответствующие права доступа к проекту и сайту SharePoint проекта. Учетная запись нового разработчика должна также иметь права доступа к SQL Server Reporting Services, чтобы разработчик мог просматривать отчеты, представленные на портале проекта.

Порядок операций

Шаг 1 - предоставление доступа к командному проекту

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

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

Шаг 2 - предоставление доступа к сайту проекта

На этом шаге новый член группы получает доступ к сайту проекта SharePoint. Выполните следующие действия:

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

Шаг 3 - предоставление доступа к службам SQL Server Report Services

На этом шаге новому члену команды предоставляется доступ к SQL Report Services. Выполните следующие действия:

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

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

Область применения

Описание

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

Содержание

Задача

Обзор

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

Порядок операций

Прежде всего

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

Шаг 1 - тестирование сборки

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

Шаг 2 - включение анализа кода в сборку

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

Шаг 3 - тестирование анализа кода

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

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

Как создать собственный отчет в Visual Studio 2005 Team Foundation Server

Область применения

Описание

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

Содержание

Задачи

Обзор

Отчеты, поставляемые с VSTS, основаны на использовании SQL Server Reporting Services. С помощью конструктора отчетов Visual Studio (Business Intelligence Development Studio) из комплекта клиентских инструментов SQL Server 2005 можно редактировать готовые отчеты или создавать собственные. Создание собственного отчета в Visual Studio начинается с создания проекта отчетов. Затем создаются источники данных для подключения к реляционной базе данных TFS и базе данных Online Analytical Processing (OLAP) .

Порядок операций

Прежде всего

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

Шаг 1 - создание нового проекта отчетов

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

Шаг 2 - создание источников данных

Чтобы редактировать и публиковать настроенный отчет, необходимо добавить источники данных для хранилища данных Team Foundation Server и OLAP -куб. После добавления этих источников данных в проект Visual Studio, отчет может закачивать данные с сервера.

Создание источника данных хранилища

Создание источника данных OLAP

Шаг 3 - создание нового отчета в проекте

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

Шаг 4 - изменение отчета

Добавив отчет в проект, отредактируйте его:

Теперь можно редактировать отчет, перетаскивая меры и измерения из дерева Dataset на панели Query Pane и Filter Pane. Компоновка отчета меняется на вкладке Layout. Увидеть, как будет выглядеть отчет, можно на вкладке Preview.

Шаг 5 - развертывание отчета на Team Foundation Server

После редактирования отчета его можно развернуть на портале отчетов командного проекта:

Шаг 6 - тестирование отчета

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

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

Как создать отчет о развитии рисков в Visual Studio 2005 Team Foundation Server

Область применения

Описание

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

Содержание

Задачи

Обзор

Отчеты, поставляемые с VSTS, основаны на использовании SQL Server Reporting Services. С помощью конструктора отчетов Visual Studio (Business Intelligence Development Studio) из комплекта клиентских инструментов SQL Server 2005 можно редактировать готовые отчеты или создавать собственные. Создание собственного отчета в Visual Studio начинается с создания проекта отчетов. Затем создаются источники данных для подключения к реляционной базе данных TFS и базе данных Online Analytical Processing (OLAP) . В этой статье рассказано, как создать с нуля простой отчет о динамике рисков ( Risk over Time ), который показывает количество рабочих элементов Risk за данный период времени.

Порядок операций

Прежде всего

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

Шаг 1 - создание нового проекта отчетов

На данном начальном этапе создается новый проект создания отчетов, благодаря которому вы получаете возможность добавлять новый отчет в проект и затем настраивать его. Чтобы создать новый проект создания отчетов в Visual Studio:

Шаг 2 - создание источников данных

Чтобы редактировать и публиковать настроенный отчет, необходимо добавить источники данных для хранилища данных Team Foundation Server и OLAP -куб. После добавления этих источников данных в проект Visual Studio, отчет может закачивать данные с сервера.

Создание источника данных хранилища

Создание источника данных OLAP

Шаг 3 - создание нового отчета в проекте

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

Шаг 4 - изменение отчета

Когда отчет добавлен в проект, его можно редактировать:

Шаг 5 - развертывание отчета на Team Foundation Server

После редактирования отчета Risk over Time его можно развернуть на портале отчетов командного проекта:

Шаг 6 - тестирование отчета

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

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

Как создать пользовательскую политику возврата после правки в Visual Studio Team Foundation Server

Область применения

Описание

В этой статье подробно разбирается процесс создания, регистрации и применения пользовательских политик возврата правок в TFS. Политика обеспечивает выполнение определенных правил при каждом возврате изменений в систему управления исходным кодом. Благодаря этому исходный код гарантированно будет соответствовать заданному набору критериев. В качестве примера в этой статье используется политика, обеспечивающая ввод комментариев ко всем возвратам изменений. Для реализации пользовательской политики возврата изменений создается класс, производный от РoliсуВa8е, и реализуются интерфейсы 1РoliсуВеАnition и 1РoliсуЕ valuation. Сборка политики регистрируется в реестре Microsoft Windows® и применяется к командному проекту.

Содержание

Задачи

Обзор

Политики возврата после правки ( check-in policies ) обеспечивают реализацию ограничений при возврате файлов в систему управления исходным кодом. В Team Foundation Server включено несколько стандартных политик, в том числе, политики для проверки выполнения и успешного прохождения модульных тестов, политики для выполнения статического анализа кода, гарантирующие соответствие кода стандартам и рекомендациям написания .NET -кода, и политики, обеспечивающие связывание рабочих элементов с возвратами правок. Еще несколько политик возврата после правки включено в комплект Microsoft Visual Studio 2005 Team Foundation Power Tool. В этой статье рассказывается, как создавать, регистрировать и применять нестандартную политику. В качестве примера приводится политика, вынуждающая разработчиков сопровождать возвращаемые изменения комментариями.

Прежде всего

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

Порядок операций

Шаг 1 - создание и сборка класса пользовательской политики

На начальном этапе в пространстве имен Microsoft.TeamFoundation.Version-Control.Client путем наследования от базового класса PolicyBase создается класс пользовательской политики. Наследование обеспечивает реализацию создаваемым классом интерфейсов IPolicyDefinition и IPolicyEvaluation. Ниже приведен пример фрагмента кода политики, которая требует обязательного ввода комментариев при каждом возврате правок.

using System;
using System.Windows.Forms;
using Microsoft.TeamFoundation.VersionControl.Client;
[Serializable]
public class CheckForCommentsPolicy : PolicyBase
{
public override string Description
{
get { return "Напоминает пользователям, что они должны сопровождать возврат изменений содержательными комментариями";
}
// Эта строка хранится с описанием политики на сервере системы управления исходным кодом.
// Если у пользователя не установлена надстройка политики, отображается эта
// строка. С ее помощью вы объясняете пользователю, как установить
// надстройку политики.
public override string InstallationInstructions
{
get { return "Инструкции по установке этой политики см. в InstallInstructions.txt."; }
}
// Эта строка определяет тип политики. Она отображается в списке политик, когда вы
// добавляете новую политику в Team Project.
public override string Type
{
get { return "Политика для проверки наличия комментариев к возврату изменений"; } }
// Эта строка является описанием типа политики. Она отображается, когда вы
// выбираете политику в диалоговом окне Add Check-in Policy.
public override string TypeDescription
{
get { return "Эта политика подскажет пользователю, на каких условиях ему будет разрешено возвратить изменения."; }
}
// Этот метод вызывается инфраструктурой написания политик при создании 
// новой политики возврата изменений или редактировании существующей. 
// Он может использоваться для отображения интерфейса для данного типа политики,
// позволяя пользователю менять параметры политики. public override bool Edit(IPolicyEditArgs args) {
// Не требует специальной конфигурации
return true; }
// Этот метод является фактической реализацией политики. Он вызывается
// инфраструктурой создания политик, когда требуется применить политику. 
// В приведеннм примере метод вызывается при возникновении различных асинхронных
// событий, которые могли привести к недействительности текущего списка
// нарушений политики.
public override PolicyFailure[] Evaluate()
{
string proposedComment = PendingCheckin.PendingChanges.Comment;
if (String.IsNullOrEmpty(proposedComment))
{
return new PolicyFailure[] {
new PolicyFailure("Пожалуйста, сопроводите возвращаемые изменения комментариями", this) }; }
else {
return new PolicyFailure[0]; } }
// Этот метод вызывается двойным щелчком нарушения политики в интерфейсе.
// В данном случае на экран выводится сообщение,  предлагающее пользователю
// ввести комментарий.
public override void Activate(PolicyFailure failure)
{
MessageBox.Show("Пожалуйста, сопроводите возвращаемые изменения комментариями.", "Как устранить нарушение политики"); }
// Этот метод вызывается, если пользователь нажимает кнопку F1 при активном
// нарушении политики в интерфейсе. В данном примере на экран выводится сообщение.
public override void DisplayHelp(PolicyFailure failure)
{
MessageBox.Show("Данная политика напоминает о необходимости сопровождения возвращаемых изменений комментариями.", 
 "Prompt Policy Help");
 } 
}

Шаг 2 - регистрация класса пользовательской политики в реестре Windows

На этом шаге вы добавите запись в реестр Windows, благодаря чему ваша политика будет отображаться в диалоговом окне Add Check-in Policy. Учтите, что сборка политики должна быть установлена на все компьютеры, где предполагается ее использовать. К ним относятся компьютер администратора командного проекта, который должен связать политику с проектом, и все компьютеры членов команды, на которых эта политика фактически реализуется.

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

Шаг 3 - применение пользовательской политики

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

Шаг 4 - проверка работоспособности пользовательской политики

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

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

Как создать дерево кода в Team Foundation Server

Область применения

Описание

В этой статье подробно разбирается процесс создания в TFS дерева исходного кода. Цель статьи - познакомить вас со всеми этапами создания собственного дерева исходного кода.

Содержание

Задачи

Обзор

Чтобы добавить решение в систему управления исходным кодом, достаточно просто щелкнуть его правой кнопкой в Solution Explorer и выбрать команду Add Solution To Source Control. Однако такой вариант не позволяет явно настроить структуру дерева исходного кода в системе управления исходным кодом. Явно описывая структуру каталогов, вы можете организовать исходный код под папками верхнего уровня и использовать отдельные папки верхнего уровня для размещения основного исходного кода и его ответвлений, например, ветвей, используемых при разработке или для обслуживания готовых выпусков.

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

Порядок операций

Шаг 1 - создание командного проекта

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

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

Шаг 2 - создание сопоставления рабочей области

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

>Сопоставление рабочей области можно создать двумя способами:

Явное задание сопоставления рабочей области

Выполнение операции Get для командного проекта

Шаг 3 - создание структуры каталогов в системе управления исходным кодом

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

/Main
		/Source
			/MyApp1 					-> Содержит MyApp1.sln
				/Source 				-> Папка-контейнер
/ClassLibrary1 			-> Содержит ClassLibrary1.csproj
/MyApp1Web 			-> Содержит Default.aspx
/UnitTests 				-> Содержит проекты модульных тестов
/ClassLibrary1Tests 		-> Проект тестирования для ClassLibrary1
/MyApp1WebTests 		-> Проект тестирования для MyApp1Web
/Build 					-> Содержит результат сборки (двоичные файлы)
/Docs 					-> Содержит проектную документацию и пр.
/TestCases 				-> Содержит документацию по тестированию
/Development
/FeatureBranch1
/Source
/MyApp1
/Source
/MyApp1Web
/ClassLibrary1
/UnitTests
/ClassLibrary1Tests
/MyApp1WebTests
/FeatureBranch2
/Releases
/Release1
/MyApp1
/Source
/ClassLibrary1
/MyApp1Web
/UnitTests
/ClassLibrary1Tests
/MyApp1WebTests
/Release 1.1
/Release 1.2

Создание структуры каталогов на сервере:

Шаг 4 - добавление исходного кода в дерево

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

Создание нового файла решения Visual Studio

Добавление в решение нового веб-сайта

Добавление в решение нового проекта библиотеки классов

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

В Solution Explorer щелкните решение правой кнопкой мыши и выберите Add Solution to Source Control. Ваше решение и два проекта будут добавлены в Team Foundation Source Control.

Теперь дерево исходного кода в системе управления исходным кодом должно выглядеть так:

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

Как настроить шаблон процесса в Visual Studio Team Foundation Server

Область применения

Описание

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

Содержание

Задачи

Обзор

Visual Studio Team System (VSTS) и TFS предоставляют собой интегрированную среду с поддержкой большинства этапов процесса разработки ПО. Методология поддержки рабочего цикла командных проектов реализована в TFS при помощи шаблонов процессов. Шаблон процесса ( process template ) - это набор XML -файлов со спецификациями процессов и артефактов, составляющих конкретную методологию. Редактирование шаблона процесса заключается в изменении стандартных типов рабочих элементов, настроек безопасности, параметров системы управления исходным кодом и отчетов.

Изменить шаблон можно, вручную редактируя XML -файлы, однако проще делать это при помощи инструмента Process Editor из комплекта Team Foundation Server Power Tool. Его интерфейс существенно упрощает процесс настройки. К тому же, редактирование XML -файлов вручную чревато большим количеством ошибок.

Чтобы настроить шаблон процесса, необходимо скачать его с сервера, а затем с помощью Process Editor внести необходимые изменения.

Порядок операций

Шаг 1 - установка редактора процессов

На начальном этапе выполняется установка инструмента Process Editor - удобного средства просмотра и настройки шаблонов процессов. Process Editor - это часть Team Foundation Server Power Tool, представляющая собой набор расширений, инструментов и утилит командной строки.

Шаг 2 - выбор шаблона процесса

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

MSF Agile

Шаблон процесса MSF Agile прост и потому подходит, главным образом, для небольших, срочных или неформальных проектов по разработке ПО. Он основан на сценариях и действиях, управляемых контекстом, и ориентирован как на проект, так и на участников (людей). Шаблон процесса MSF Agile code> может использоваться в следующих сценариях:

MSF CMMI

Шаблон процесса MSF CMMI предназначен для более серьезных проектов по разработке ПО. Он расширяет функциональность шаблона MSF Agile, предоставляя поддержку аудита, верификации и формальных процессов. Этот шаблон может использоваться в следующих сценариях:

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

Шаг 3 - загрузка шаблона процесса

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

Шаг 4 - открытие шаблона в редакторе процесса

Загрузите скачанный шаблон процесса в Process Editor для изменения различных параметров.

Допустим, вы назвали новый шаблон процесса My Template.

Шаг 5 - изменение типов рабочих элементов

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

Добавление новых типов рабочих элементов

Например, можно создать новую ошибку "My Bug" , скопировав рабочий элемент Bug, а затем отредактировать тип рабочего элемента и изменить его поведение.

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

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

Добавление в рабочий элемент нового поля

В качестве примера добавим в созданный ранее тип рабочего элемента My Bug новое поле Security Impact. Выполните следующие действия:

Удаление поля из рабочего элемента

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

Удалим одно из полей созданного ранее типа рабочего элемента My Bug:

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

Редактирование последовательности операций рабочего элемента

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

Примечание Если панель инструментов WITDesigner не отображается, выберите команду Toolbox в меню View Visual Studio.

Шаг 6 - изменение стандартных рабочих элементов

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

Попробуйте удалить задачу Setup: Migration of Source Code, выполнив следующие действия:

Задача по умолчанию Setup: Migration of Source Code более не будет создаваться при создании нового проекта на основе данного шаблона.

Шаг 7 - изменение и управление запросами

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

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

Этот запрос отобразит все рабочие элементы, у которых значение в поле MyBug.CustomField.1 превышает 1.

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

Шаг 8 - изменение областей и итераций

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

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

Теперь для всех новых проектов, использующих ваш шаблон процесса, автоматически будут определены области UI и Back End.

Шаг 9 - изменение групп и прав доступа

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

Шаг 10 - изменение настроек системы управления исходным кодом

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

Примечание В этой версии Process Editor недопускается внесение изменений на вкладке Permissions.

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

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

Шаг 11 - изменение портала проекта

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

Шаг 12 - изменение отчетов

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

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

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

Шаг 13 - выгрузка измененного шаблона процесса на сервер

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

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

Создайте новый проект на основании этого шаблона процесса:

Просмотрите измененные вами области:

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

Как настроить отчет в Visual Studio 2005 Team Foundation Server

Область применения

Описание

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

Содержание

Задачи

Обзор

Отчеты, поставляемые с VSTS, основаны на использовании SQL Server Reporting Services. С помощью конструктора отчетов Visual Studio (Business Intelligence Development Studio) из комплекта клиентских инструментов SQL Server 2005 можно редактировать готовые отчеты или создавать собственные.

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

Порядок операций

Прежде всего

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

Шаг 1 - создание нового проекта отчетов

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

Шаг 2 - экспорт отчета

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

Шаг 3 - создание источников данных

Чтобы редактировать и публиковать настроенный отчет, необходимо добавить источники данных для хранилища данных Team Foundation Server и OLAP -куб. После добавления этих источников данных в проект Visual Studio отчет может закачивать данные с сервера.

Создание источника данных хранилища

Создание источника данных OLAP

Шаг 4 - добавление отчета в проект

Теперь, когда в проект добавлены источники данных, можно импортировать отчет, экспортированный на шаге 2:

Шаг 5 - редактирование отчета

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

Шаг 6 - развертывание отчета на Team Foundation Server

Внеся изменения в отчет, разверните его на портале отчетов командного проекта:

Шаг 7 - тестирование отчета

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

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

Как управлять проектами в Visual Studio Team Foundation Server

Область применения

Описание

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

Содержание

Задачи

Обзор

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

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

Порядок операций

Прежде всего

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

Шаг 1 - выбор шаблона процесса

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

Шаг 2 - создание командного проекта

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

На сервере TFS будет создан командный проект на базе шаблона процесса MSF Agile.

Шаг 3 - создание групп доступа (при необходимости)

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

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

Чтобы создать новую группу, вы должны быть членом группы Project Administrators. Быть администратором Microsoft Windows® вам не нужно.

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

Шаг 4 - добавление членов команды в Team Foundation Server

На этом этапе определяются ресурсы, которые будут работать над проектом, и их роли. Затем члены команды добавляются в TFS. Пользователей можно добавлять в существующие группы проекта или группы уровня сервера. Также вы должны добавить пользователей во вновь созданные вами группы. Для этого вы должны быть членом группы Team Foundation Administrators.

Шаг 5 - определение итерационного цикла

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

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

Шаг 6 - описание сценариев проекта в TFS

Описание сценария проекта в TFS позволяет лучше спланировать ход проекта и отслеживать его выполнение.

Создание сценария в проекте на основе шаблона процесса MSF Agile

Шаг 7 - выбор сценариев для итерации

Теперь описанные сценарии нужно распределить по итерациям. Этот этап повторяется на каждом итерационном цикле.

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

Шаг 8 - определение требований QoS

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

Шаг 9 - планирование итерации

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

Задачи разработки

Задачи тестирования

Прочее

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

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

Шаг 10 - отслеживание процесса разработки

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

Ошибки

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

Управление выпусками

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

Тестирование

Отчеты о тестировании позволяют следить за эффективностью испытаний. Доступны следующие отчеты о тестировании:

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

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

Отчет доступен в шаблоне MSF CMMI.

Рекомендации по работе с областями и итерациями

При работе с областями и итерациями необходимо учитывать следующие соображения:

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

Как перенести исходный код из Visual Source Safe в Team Foundation Server

Область применения

Описание

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

Содержание

Задачи

Обзор

В Team Foundation Server включены инструменты, облегчающие перенос исходного кода из базы данных Visual Source Safe (VSS) в систему управления исходным кодом TFS. В частности, в TFS предлагается инструмент VSS Converter, позволяющий переносить файлы, папки, историю версий, метки и пользовательскую информацию. VSS Converte r используется в два этапа: сначала для выявления потенциальных проблем с его помощью выполняется анализ существующей базы данных VSS, а затем выполняется фактический перенос.

Следуя рекомендациям из этой статьи, вы успешно перенесете свой исходный код. Основные проблемы, которые могут при этом возникнуть, обусловлены некоторыми различиями процесса управления исходным кодом в TFS по сравнению с VSS. Например, в TFS не поддерживается совместное использование файлов. При переносе общий файл копируется в целевую папку в том состоянии, в котором он был на момент начала совместного использования. Ветвление в VSS осуществляется через совместное использование файлов, поэтому перенос ветвей также заключается в копировании файлов в целевую папку системы управления исходным кодом TFS. Поскольку TFS/ не поддерживает фиксацию версий, инструмент VSSConver-ter маркирует все файлы, версии которых ранее были фиксированы в базе данных VSS, меткой "PINNED", чтобы их можно было найти в системе управления исходным кодом TFS.

Прежде всего

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

Порядок операций

Шаг 1 - создание резервной копии базы данных VSS

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

По умолчанию эти файлы размещаются в папке \Program Files\Microsoft Visual Studio\VSS.

Шаг 2 - анализ базы данных VSS с точки зрения целостности данных

На данном этапе с помощью утилиты Visual SourceSafe Analyze выявляются и исправляются проблемы целостности в базе данных.

Шаг 3 - анализ проектов в VSS

Теперь выберите проекты, которые будете переносить, и запустите инструмент командной строки TFS VSSConverter.exe, чтобы выявить в базе данных VSS потенциальные проблемы, способные вызвать трудности при миграции кода.

<?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>

<?xml version="1.0" encoding="utf-8" ?>
<UserMappings xmlns:xsi="
  http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <!--

<UserMap From="Jane" 
To="MyDomain\Janep"></UserMap> 
Это сопоставление приводит к тому, что все действия VSS-пользователя "Jane"
при переносе будут отнесены к пользователю Team Foundation 
"MyDomain\Janep". -->
 <UserMap From="ADMIN" To="Contoso\Administrator" /> 
  <UserMap From="Dave" To="Contoso\DaveM" /> 
   <UserMap From="Chris" To="Contoso\ChrisP" /> 
     <UserMap From="John" To="Contoso\JohnR" /> 
 </UserMappings>

Шаг 4 - подготовка к переносу проектов

На данном этапе с помощью инструмента VSSConverter.exe выполняется перенос проектов VSS.

<SourceControlConverter> 
 <ConverterSpecificSetting> …
   </ConverterSpecificSetting> 
    <Settings>
   <TeamFoundationServer name="YourTFSServerName"
     port="PortNumber" protocol="http"> 
   </TeamFoundationServer> 
 </Settings> … 
 </SourceControlConverter>

<?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>

В разделе <ProjectMap> для каждой переносимой папки VSS вместо MyFirstProject укажите исходные папки VSS и вместо MyTeamProject-One - заданные папки системы управления исходным кодом TFS. Включите запись <Project> для всех проектов, которые хотите переносить.

Шаг 5 - перенос проектов

Скопируйте базу данных VSS в локальную папку (например, C:\VSSData-bases ) на компьютере, на котором хотите выполнить анализ и перенос. Базу данных VSS можно перенести и в совместно используемую папку на удаленном компьютере, но миграция в этом случае займет намного больше времени.

Дополнительные рекомендации

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

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

Как выполнить слияние без основы в Visual Studio Team Foundation Server

Область применения

Описание

В этой статье подробно разбирается процесс слияния двух ветвей, которые никак не связаны друг с другом. Процесс слияния элементов, не являющихся непосредственными ответвлениями друг друга, называется слиянием без общей основы ( baseless nerge ). Выполняется такое слияние с помощью команды Tf merge. Осуществить слияния без основы из интерфейса Visual Studio невозможно.

Содержание

Задачи

Обзор

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

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

Порядок операций

Шаг 1 - оценка необходимости выполнения слияния без основы

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

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

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

Шаг 2 - выполнение слияния без основы с использованием Tf.exe

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

Если сопоставление рабочей области не задано, Visual Studio предложит выбрать папку на локальном диске

Tf merge /baseless <исходный путь> <целевой путь> /recursive

Tf merge /baseless c:\data\proj1 c:\data proj2 /recursive

tf merge /baseless <исходный путь> 
  <целевой путь> / recursive / version:
   < набор изменений, из которого переносятся изменения>~
     <набор изменений, в который переносятся изменения>

tf merge /baseless c:\data\proj1 c:\data\proj2 /recursive /version: C123~C125

Шаг 3 - разрешение конфликтов, возникших при слиянии

При слиянии без основы часто возникают конфликты. После выполнения команды Tf.exe на экран выводится диалоговое окно Resolve Conflicts со списком файлов, в которых возникли конфликты.

Шаг 4 - возврат изменений, внесенных в результате слияния, в систему управления исходным кодом

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

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

Как настроить непрерывную интеграцию в Visual Studio Team Foundation Server

Область применения

Описание

В Visual Studio 2005 Team Foundation Server нет стандартного решения для непрерывной интеграции ( Continuous Integration, CI ), но имеется вся инфраструктура, необходимая для реализации собственного решения. В этой статье подробно разбирается процесс настройки сборки CI в TFS с помощью решения, предоставленного группой VSTS. Это решение устанавливает веб-службу, выполняющуюся от имени учетной записи с правом доступа к серверу TFS. Благодаря подписке на событие CheckinEvent эта веб-служба будет запускать сборку при каждом возврате правок.

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

Содержание

Задачи

Обзор

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

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

Порядок операций

Прежде всего

Убедитесь, что учетная запись, от имени которой выполняется служба сборки, обладает разрешением Start a build на сервере Team Foundation Server.

Шаг 1 - создание и тестирование сборки

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

Важно! Убедитесь, что учетная запись TFSService, от имени которой выполняются службы сборки, обладает полным доступом к общей папке для размещения результатов сборки, заданной в Team Build Type Wizard.

Шаг 2 - установка решения непрерывной интеграции

Установите решение непрерывной интеграции, предоставленное командой .

При установке в корневой папке сервера уровня приложений TFS создается виртуальный каталог. Это должен быть веб-сайт Internet Information Services (IIS) с именем Team Foundation Server, связанный с портом 8080.

Шаг 3 - настройка решения непрерывной интеграции

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

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

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

Ниже приведен пример настроек:

…
<add key="1" value="TeamServer=http://TFSRTM:8080;TeamProjectName=Adventure
Works;BuildType=Test Build"/>
…

Шаг 4 - подписка на событие CheckinEvent

Подпишитесь на событие CheckinEvent, используя инструмент bisubscribe, поставляемый с TFS.

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

Шаг 5 - тестирование непрерывной интеграции

Теперь нужно проверить правильность выполнения CI -сборки.

Устранение неисправностей

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

Шаг 6 - настройка уведомлений по электронной почте

Можно настроить оповещение всех заинтересованных сторон о завершении сборки по электронной почте.

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

Как настроить плановую сборку в Visual Studio Team Foundation Server

Область применения

Описание

В Visual Studio 2005 Team Foundation Server не предусмотрена возможность плановых сборок, но с помощью команды TFSBuild разработчик легко реализует их самостоятельно. В этой статье подробно разбирается процесс настройки плановой сборки с помощью команды TFSBuild и планировщика задач Microsoft Windows®.

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

Содержание

Задачи

Обзор

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

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

Порядок операций

Прежде всего

Убедитесь, что учетная запись, от имени которой выполняется служба сборки, обладает разрешением Start a build на сервере Team Foundation Server.

Шаг 1 - создание и тестирование сборки

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

Важно! Убедитесь, что учетная запись TFSService, от имени которой выполняются службы сборки, обладает полным доступом к общей папке для размещения результатов сборки, заданной в Team Build Type Wizard.

Шаг 2 - создание команды для запуска TFSBuild

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

Если требуется переопределить имя компьютера и путь к папке сборки, команда выглядит так: TfsBuild start <TFS-сервер> <КомандныйПроект> <ИмяТипаСборки> /m:<ИмяКомпьютера> /d:<ПапкаСборки>

Шаг 3 - тестирование команды для запуска TFSBuild

Проверим правильность выполнения команды TFSBuild.

Шаг 4 - создание пакетного файла

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

Шаг 5 - тестирование пакетного файла

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

Шаг 6 - добавление плановой задачи

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

Шаг 7 - тестирование плановой задачи

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

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

Как структурировать приложения ASP.NET в Visual Studio Team Foundation Server

Область применения

Описание

В этой статье подробно разбирается процесс организации и структурирования веб-приложений ASP.NET для Team Foundation Server. Здесь описана рекомендованная структура дерева исходного кода системы управления исходным кодом TFS.

Содержание

Задачи

Обзор

В этой статье рассказано, как создавать структуру каталогов системы управления исходным кодом для веб-приложений ASP.NET. Поскольку в веб-проекты ASP.NET часто включаются дополнительные библиотеки классов, это необходимо предусмотреть в структуре. Папки для хранения веб-проектов ASP.NET располагаются в системе управления исходным кодом под папками верхнего уровня /Main/Source. Такая структура позволяет добавлять папки Development и Releases при необходимости создания ветвей для изолированной разработки и обслуживания предыдущих выпусков. Дополнительную информацию о создании структуры каталогов верхнего уровня вы найдете в разделе "Как структурировать папки управления исходным кодом в Visual Studio Team Foundation Server ".

Порядок операций

Шаг 1 - создание локальных папок веб-проекта

На этом этапе вы создадите на своем компьютере локальную структуру каталогов для веб-проекта. Чтобы обеспечить единый подход к командной разработке и эффективную организацию проектов на своем компьютере, сгруппируйте разрабатываемый исходный код всех командных проектов, над которыми вы работаете, в одной корневой папке, например, C:\Dev-Projects. Если такой папки еще нет на компьютере, создайте ее.

Шаг 2 - создание пустого решения

Начните создание веб-приложения ASP.NET с явного создания файла решения Visual Studio (.sln) . Затем добавьте в него свой веб-сайт и все необходимые дополнительные проекты, например, библиотеки классов. Вот как создается решение в папке верхнего уровня C:\DevProjects.

Шаг 3 - добавление веб-сайта в решение

Теперь добавьте в свое решение веб-сайт ASP.NET. Эта процедура немного варьируется в зависимости от типа веб-сайта, т.е., от того, создается веб-сайт в локальной файловой системе с использованием функций веб-разработки Visual Studio или на веб-сервере с использованием Internet Information Services (IIS) .

Сайт в файловой системе

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

Сайт на веб-сервере

Создание веб-сайта ASP.NET на базе веб-сервера IIS, доступ к которому при разработке будет осуществляться по протоколу HTTP, начинается с явного создания виртуального каталога. Необходимо, чтобы каталог веб-сайта располагался в заданном расположении, а не в папке \inetpub\wwwroot.

Создание виртуального каталога веб-сайта

Добавление веб-сайта в решение

Шаг 4 - добавление библиотеки классов (при необходимости)

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

Все новые проекты будут добавляться в папку Source.

Шаг 5 - проверка структуры решения

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

Шаг 6 - проверка локальной структуры каталогов

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

Шаг 7 - добавление решения в систему управления исходным кодом

На данном этапе вы добавите решение в систему управления исходным кодом TFS.

Щелкните правой кнопкой мыши свое решение и выберите Add Solution to Source Control.

В диалоговом окне Add Solution MyWebAppSln to Source Control выберите свой командный проект.

Щелкните Make New Folder и назовите новую папку Main.

Выделите вновь созданную папку Main и щелкните Make New Folder. Назовите новую папку Source.

Выберите вновь созданную папку Source и щелкните OK.

Проверьте структуру папок в системе управления исходным кодом, дважды щелкнув Source Control в Team Explorer. Структура должна выглядеть следующим образом:

Теперь вы можете просматривать изменения, ожидающие возвращения на сервер, и возвращать файлы исходного кода. Для этого в меню View выберите Other Windows и щелкните Pending Changes. Выберите свой проект и исходные файлы, которые необходимо возвратить, введите комментарий к возвращаемым изменениям и щелкните Check In.

Рекомендации по работе с общим кодом

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

Использование кода из общей папки

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

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

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

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

Создание ветви общего кода

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

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

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

Как структурировать приложения Windows в Visual Studio Team Foundation Server

Область применения

Описание

В этой статье подробно разбирается процесс организации и структурирования приложений Windows Form в Team Foundation Server. Описана рекомендованная структура дерева исходного кода в системе управления исходным кодом TFS.

Содержание

Задачи

Обзор

В статье показано, как создавать структуру каталогов системы управления исходным кодом для приложений Windows Forms. Поскольку в проекты Windows Forms часто включаются дополнительные библиотеки классов и элементов управления, структура должна это учитывать. В системе управления исходным кодом папки для хранения проектов Windows Forms располагаются под папками верхнего уровня /Main/Source. Такая структура позволяет добавлять папки Development и Releases при необходимости создания ветвей для изолированной разработки и обслуживания выпущенных версий. Дополнительную информацию о создании структуры каталогов верхнего уровня вы найдете в разделе "Как структурировать папки управления исходным кодом в Visual Studio Team Foundation Server ".

Порядок операций

Шаг 1 - создание локальных папок проекта Windows Forms

На этом этапе вы создадите на своем компьютере локальную структуру каталогов для проекта Windows Forms. Чтобы обеспечить единый подход к командной разработке и эффективную организацию проектов на своем компьютере, сгруппируйте разрабатываемый исходный код всех командных проектов, над которыми вы работаете, в одной корневой папке, например, C:\DevProjects. Если такой папки еще нет на компьютере, создайте ее.

Шаг 2 - создание пустого решения

Начните создание приложения Windows Forms с явного создания файла решения Visual Studio (.sln) . Затем добавьте в него проект Windows Forms и все необходимые дополнительные проекты, например, библиотеки классов или элементов управления. Вот как создается решение в папке верхнего уровня C:\DevProjects.

Шаг 3 - добавление проекта Windows Forms в решение

Добавьте проект Windows Forms в свое решение.

Шаг 4 - добавление библиотеки элементов управления (при необходимости)

Если в приложении Windows Forms используются дополнительные библиотеки элементов управления, добавьте их следующим образом:

Шаг 5 - добавление библиотеки классов (при необходимости)

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

Шаг 6 - проверка структуры решения

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

Шаг 7 - проверка локальной структуры каталогов

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

Шаг 8 - добавление решения в систему управления исходным кодом

Добавьте в систему управления исходным кодом TFS свое решение, содержащее проект Windows Forms, а также, возможно, библиотеки классов и элементов управления.

Щелкните правой кнопкой мыши MyApp и выберите Add Solution to Source Control.

В диалоговом окне Add Solution MyApp to Source Control выберите свой командный проект.

В диалоговом окне щелкните Make New Folder и назовите новую папку Main.

Выделите вновь созданную папку Main и щелкните Make New Folder. Назовите новую папку Source.

Выделите вновь созданную папку Source и щелкните OK.

Проверьте структуру папок в системе управления исходным кодом, щелкнув дважды Source Control в Team Explorer. При этом откроется Source Control Explorer. Структура папок должна выглядеть следующим образом:

Теперь вы можете просматривать изменения, ожидающие возвращения на сервер, и возвращать файлы исходного кода. В меню View выберите Other Windows и щелкните Pending Changes. Выберите проект и исходные файлы, которые необходимо возвратить, введите комментарий к возвращаемым изменениям и щелкните Check In.

Рекомендации по работе с общим кодом

Существует два основных варианта использования общего кода в веб-приложениях Windows Forms:

Использование кода из общей папки

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

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

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

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

Создание ветви общего кода

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

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

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

Как структурировать папки управления исходным кодом в Visual Studio Team Foundation Server

Область применения

Описание

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

Содержание

Задачи

Обзор

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

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

{
/Main	->Может содержать файлы решений (.sln),
охватывающих несколько проектов
/Source
/MyApp1	^Содержит файл MyApp1.sln
/Source	^Содержит папку для всего исходного кода
/ClassLibrary1 ^Содержит ClassLibrary1.csproj
/MyApp1Web	^Содержит Default.aspx
/Build	^Содержит результат сборки (двоичные файлы)
/Docs	^Содержит документацию по продукту и пр.
/Tests	^Содержит тесты
/Development
/FeatureBranch1
/Source /MyApp1 /Source
/MyApp1Web /ClassLibrary1 /FeatureBranch2
/Releases
/Release1 /Source /MyApp1 /Source
/MyApp1Web /ClassLibrary1 /Release 1.1 /Release 1.2 }

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

Порядок операций

Шаг 1 - создание сопоставления рабочей области

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

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

Явное создание сопоставления рабочей области

Выполнение операции Get для командного проекта

Шаг 2 - создание папки Main

Теперь создадим в системе управления исходным кодом новую корневую папку Main для вашего командного проекта. Она используется как корневой контейнер для исходного кода и других артефактов проекта. В ней также могут располагаться файлы решений Visual Studio (.sln) , охватывающих несколько проектов. Папки решений также хранятся в папках соответствующих приложений, располагающихся на более низком уровне структуры дерева. Чтобы создать папку Main, выполните следующие действия:

Шаг 3 - создание папок для артефактов проекта

Далее в папке Main создаются папки для размещения дерева исходного кода и сопутствующих артефактов, например, сборок, документации, файлов сценариев и тестов:

{ /Main
/Build
/Docs
/Source
/Tests }

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

Шаг 4 - добавление решения в дерево исходного кода

Теперь добавим в дерево исходного кода TFS решение Visual Studio (.sln) , проект ( .vsproj, .vbproj ) и исходные файлы.

Поскольку на шаге 1 вы сопоставили корневой узел с папкой C:\ DevProjects\MyTeamProject1, убедитесь, что структуры папок на клиенте и на сервере синхронизированы. Файл решения (.sln) должен находиться в папке C:\DevProjects\MyTeamProject1\Main\Source\MyApp1. Связанные с проектом файлы компонентов MyApp1Web и ClassLibrary1 должны располагаться в папке C:\DevProjects\MyTeamProject1\Main\Source\MyApp1\ Source.

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

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

{
/Main /Source /MyApp1 /Source
/MyApp1Web /ClassLibrary1 /Build /Docs /Tests }

Дополнительную информацию о настройке структуры каталогов на стороне клиента вы найдете в статьях "Как структурировать приложения Windows в Visual Studio Team Foundation Server " и "Как структурировать приложения ASP.NET в Visual Studio Team Foundation Server ".

Структура каталогов при наличии в проекте модульных тестов

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

{
/Main /Source /MyApp1 /Source
/MyApp1Web /ClassLibrary1 /UnitTests /Build /Docs /Tests }

Шаг 5 - создание папки Development для изоляции разработки (при необходимости)

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

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

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

{ /Development
/FeatureBranch1 /Source /MyApp1 /Source
/MyApp1Web /ClassLibrary1 /FeatureBranch2
/Main /Source /MyApp1 /Source
/MyApp1Web /ClassLibrary1 /Build /Docs /Source /Tests }

Шаг 6 - создание папки Releases для изоляции выпущенных сборок (при необходимости)

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

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

{
/Main /Source /MyApp1 /Source
/MyApp1Web /ClassLibrary1 /Build /Docs /Source /Tests
/Releases
/Release1 /Source /MyApp1 /Source
/MyApp1Web
/ClassLibrary1 /Release 1.1 /Release 1.2 }

Дополнительные рекомендации

При создании структуры каталогов в TFS учитывайте следующие рекомендации:

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