Заметки консультанта

Шамрай Александр Владимирович

Краткие практические рекомендации: система контроля версий

<< Назад

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

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS)

Microsoft Visual Studio Team System

Содержание

Организация доступа к системе контроля версий

Как использовать систему контроля версий из клиентов, не использующих Visual Studio

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

Как работать в автономном режиме

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

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

Как удалить разработчика, который покинул проект

Как предоставить права доступа непосредственно в дереве исходного кода

Как перенести Team Foundation Version Control на другой сервер

Ветвление / маркирование метками / слияние

Как использовать метки

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

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

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

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

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

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

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

Как использовать ветвление для изоляции внешних зависимостей

Как вывести из обращения старую версию

Как выполнять слияние

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

Как разрешать конфликты при слиянии

Сборки

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

Регистрации изменений и политики регистрации изменений

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

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

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

Как отменить регистрацию изменений

Как разрешить конфликт

Как избегать конфликтов

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

Изъятие, получение и блокировка

Как синхронизировать свой компьютер с TFS

Как подготовить файл к редактированию

Совместное использование кода

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

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

Зависимости

Как работать со ссылками на Веб-сервисы

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

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

Как организовывать доступ к TFS по Интернет

Как оптимизировать производительность прокси-сервера TFS Version Control

Миграция

Как перенести исходный код из Visual SourceSafe

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

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

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

Как организовывать дерево исходного кода

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

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

Безопасность

Как защитить канал между рабочей станцией разработчика и TFS

Возможность временно отложить изменения

Как использовать возможность временно откладывать изменения для резервного копирования ожидающих регистрации изменений

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

Организация доступа к системе контроля версий

• Как использовать систему контроля версий из клиентов, не использующих Visual Studio

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

• Как работать в автономном режиме

Как использовать систему контроля версий из клиентов, не использующих Visual Studio

Организовать доступ к Microsoft® Visual Studio® 2005 Team System (VSTS) Team Foundation Server (TFS) Version Control из других клиентов можно, используя один из приведенных ниже подходов:

Интеграцию с использованием Microsoft Source Code Control Interface (MSSCCI)

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

Специальную интеграцию

Интеграция с использованием MSSCCI

Служба MSSCCI позволяет напрямую работать с TFS Version Control следующим клиентам:

Microsoft Visual Studio .NET 2003

Microsoft Visual C++® 6 SP6

Microsoft Visual Basic® 6 SP6

Microsoft Visual FoxPro® 9 SP1

Microsoft Access™ 2003 SP2

Microsoft SQL Server™ Management Studio

Sparx Systems Enterprise Architect 61

Sybase PowerBuilder 105

Toad for SQL Server 2.0

Поведение службы MSSCCI отличается от поведения TFS Version Control в Visual Studio 2005 следующим образом:

При изъятии версии файла для редактирования также выполняется операция GetLatest (Получить последнюю версию).

При изъятии версии файла для редактирования применяется взаимоисключающая блокировка регистрации изменений.

Поведение для опций меню Open-from source control (Открыть из системы контроля версий) и save-to source control (cохранить в систему контроля версий) аналогично поведению в Microsoft Visual SourceSafe® (VSS).

Скачать службу MSSCCI из Microsoft MSDN® можно по адресу

http://www.microsoft.com/downloads/details.aspx?FamilyId=87E1FFBD-A484-4C3A-8776-D560AB1E6198&displaylang=en.

Служба MSSCCI не поддерживается Microsoft. Если возникли вопросы, за консультацией обращайтесь на форумы MSDN по адресу http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=22&SiteID=1.

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

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

Eclipse

клиент Linux

клиент Apple Macintosh

клиент HTML Web

Если требуется обеспечить возможность доступа к TFS Version Control для клиентов Eclipse IDE, Linux или Macintosh, установите Teamprise (http://www.teamprise.com/).

Если вам нужен доступ к TFS Version Control из Internet только для чтения, рассмотрите возможность использования Team System Web Access (http://msdn2.microsoft.com/en-us/teamsystem/bb676728.aspx).

Специальная интеграция

Для других клиентов в настоящее время нет решения для интеграции. Можно организовать доступ к TFS Version Control из командной строки или создать собственное решение для интеграции.

Подробнее о работе с TFS Version Control рассказывает статья «Walkthrough: Working with Team Foundation Source Control from Command Line», которая находится на Вебсайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/zthc5x3f(VS.80).aspx.

Для автоматизации работы с командной строкой используются сценарии и командные файлы. Подробнее о работе со сценариями и командными файлами рассказывается в статье «Team Foundation Source Control Scripts and Command Files» (Сценарии и командные файлы системы контроля версий TFS), которую можно найти на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/librarv/laz5aV5c(VS80).aspx.

Дополнительные источники

Скачать MSSCCI-провайдер с сайта MSDN можно по адресу http://www.microsoft.com/downloads/details.aspx?Familyld=87ElFFBD-A484-4C3A-8776-D560ABlE6198&displaylang=en.

Если требуется обеспечить возможность доступа к TFS Version Control для клиентов Eclipse IDE, Linux или Macintosh, установите Teamprise (http://www.teamprise.com/).

Если требуется обеспечить возможность доступа к TFS Version Control из Internet, установите Team System Web Access, который можно найти по адресу http://msdn2.microsoft.com/en-us/teamsystem/bb676728.aspx.

Подробнее о работе с TFS Version Control рассказывает статья «Walkthrough: Working with Team Foundation Source Control from Command Line», которую можно найти по адресу http://msdn2.microsoft.com/en-us/library/zthc5x3f(VS.80).aspx.

Подробнее о работе со сценариями и командными файлами рассказывается в статье «Team Foundation Source Control Scripts and Command Files», которую можно найти по адресу http://msdn2.microsoft.com/en-us/librarv/laz5aV5c(VS80).aspx.

Подробнее о расширяемости TFS Version Control рассказывается в статье «Walkthrough: The Version Control Object Model» (По шагам: объектная модель системы контроля версий), которую можно найти по адресу http://msdn2.microsoft.com/en-us/library/bbl87335(VS.80).aspx.

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

Для автоматизации повседневных задач по контролю версий используется инструмент командной строки Team Foundation (tf.exe). Он позволяет выполнять все операции, доступные в Source Control Explorer, включая операции системы контроля версий (add, check-in, checkout, get, lock, label и пр.), ветвление, откладывание ожидающих регистрации изменений, управление рабочими пространствами и общие задачи по администрированию.

Инструмент командной строки используется, главным образом, для автоматизации повторяющихся операций и планирования операций с помощью Microsoft Windows® Task Scheduler для их выполнения в заданное время или по заданному событию. Следующие команды также доступны только из командной строки:

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

Отмена регистрации изменений другого пользователя

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

Определение области действия метки

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

Чтобы убедиться в задании соответствующего пути и других переменных окружения, запустите инструмент командной строки из окна командной строки Visual Studio 2005 или выполните командный файл Vsvars32, который обычно находится в каталоге DriveLetter:\Program Files\Microsoft Visual Studio 8\Common7\Tools1.

1Driveletter – имя дисковода (прим. переводчика)

Tf.exe установлен как часть клиента TFS и по умолчанию располагается в папке C:\Program Files\Microsoft Visual Studio 8\Common 7\IDE.

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

tf.exe dir /s:YourTFSServer

Дополнительные источники

Больше информации представлено в статье «Walkthrough: Working with Team Foundation Source Control from Command Line», которую можно найти на Вебсайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/zthc5x3f(VS.80).aspx.

Более подробную информацию можно найти в статье «MSDN Team Foundation Source Control Command-Line Reference» (Справочник MSDN по инструменту командной строки Team Foundation Source Control) по адресу http://msdn2.microsoft.com/en-us/library/cc31bk2e(VS.80).aspx.

Как работать в автономном режиме

TFS Version Control не поддерживает работу в автономном режиме.

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

1. Вручную снять флаги read-only. По умолчанию все файлы рабочего пространства, которые не были изъяты из системы контроля версий для редактирования, маркированы как файлы только для чтения. При работе без соединения с сервером, прежде чем редактировать или удалять файлы, необходимо вручную снять флаги read-only. Для этого щелкните правой кнопкой мыши файл в Windows Explorer, щелкните Properties, уберите флажок Read-only и щелкните OK. Или можно использовать команду DOS attrib -r.

2. Редактировать файлы. Теперь файлы, для которых снят флаг read-only, можно редактировать.

3. Добавить или удалить файлы. Файлы, для которых снят флаг read-only, можно добавлять или удалять. Переименовывать файлы нельзя, потому что инструмент TFPT online не отличает операцию переименования от сочетания операций уничтожения и добавления.

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

4. Выполнить команду TFPT online. Вернувшись в режим online, выполните команду TFPT online, введя в командной строке TFPT online. По этой команде

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

Важно: В автономном режиме нельзя изменять имена файлов.

Дополнительные источники

Скачать инструмент TFPT с сайта MSDN можно по адресу http://www.microsoft.com/downloads/details.aspx?FamilVID=7324C3DB-658D-441B-8522-689C557D0A79&displaylang=en.

О Visual Studio Team Foundation Power Tool рассказывается в статье «Power Toy: tfptexe» (Мощный мини-инструмент: tfptexe) по адресу http://blogs.msdn.com/buckh/archive/2005/ll/16/493401.aspx.

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

• Как добавить нового разработчика в свой проект

• Как удалить разработчика, который покинул проект

• Как предоставить права доступа непосредственно в дереве исходного кода

• Как перенести Team Foundation Version Control на другой сервер

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

Чтобы добавить нового разработчика в свой проект, предоставьте ему соответствующее право доступа к групповому проекту и ассоциированному с ним Microsoft Office SharePoint® сайту проекта. Чтобы разработчик смог просматривать отчеты, предоставьте его учетной записи доступ к SQL Server Reporting Services.

Чтобы предоставить доступ к групповому проекту

1. Зарегистрируйтесь в Visual Studio под учетной записью, которая является членом группы Team Foundation Administrators приложения.

2. Добавьте необходимый проект в Team Explorer (если его там еще нет).

3. Щелкните правой кнопкой мыши групповой проект, выберите Team Project Settings и щелкните Group Membership (Членство в группах).

4. Выберите Project\Contributors (Проект\Участники), щелкните Properties и добавьте учетную запись нового разработчика в эту группу.

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

Чтобы предоставить доступ к SharePoint-сайту проекта

1. Выполните доступ к сайту проекта под учетной записью, которая является членом группы SharePoint Administrator сайта. Сайт проекта YourProject по умолчанию располагается по адресу http://server/sites/YourProject/default.aspx.

2. Щелкните Site Settings (Настройки сайта).

3. Под надписью Administration щелкните Manage Users (Управление пользователями).

4. Щелкните Add Users (Добавить пользователей).

5. Для учетной записи нового разработчика введите регистрационное имя в форме домен\учетнаязаписьпользователя, выберите Contributor и щелкните Next.

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

7. Щелкните Finish.

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

Чтобы предоставить доступ к SQL Server Reporting Services

1. Зарегистрируйтесь на Веб-сайте администрирования SQL Server Reporting Services под учетной записью администратора. Сайт находится по адресу http://server/reports.

2. Щелкните имя своего группового проекта.

3. Выберите вкладку Properties.

4. Выберите вкладку Security.

5. Щелкните New Role Assignment.

6. Введите регистрационное имя разработчика в Windows, выберите Browser и щелкните OK.

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

Дополнительные источники

Больше информации можно найти в статье «Team Foundation Server Default Groups, Permissions, and Roles» на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/ms253077.aspx.

Подробнее об этом рассказывается в статье «Source Control Security Rights and Permissions» (Права доступа системы контроля версий) на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/msl81761.aspx.

Как удалить разработчика, который покинул проект

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

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

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

tf workspaces /owner:domain\devuser /computer:* /server:servername

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

tf workspace /delete workspacename;domain\devuser /s:servername

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

• Групповой проект TFS — Зарегистрируйтесь в Visual Studio под учетной записью, которая является членом группы Team Foundation Administrators приложения. В Team Explorer щелкните правой кнопкой мыши проект, выберите Team Project Settings, щелкните Group Membership и удалите учетную запись разработчика из соответствующих групп (обычно, это группа Contributors).

• Сайт группового проекта SharePoint — Зарегистрируйтесь на сайте проекта, который расположен по адресу http://server/sites/yourprp/ectnome/default.aspxl под учетной записью администратора. Щелкните Site Settings, Manage Users и удалите учетную запись разработчика.

• SQL Server Reporting Services — Зарегистрируйтесь на Веб-сайте администрирования SQL Server Reporting Services под учетной записью администратора. Этот сайт расположен по адресу http://server/reports. Щелкните имя вашего группового проекта, выберите вкладку Properties, выберите вкладку Security и удалите учетную запись разработчика.

Дополнительные источники

Очистка после ухода разработчика подробнее рассматривается в статье «How to: Clean Up Files When Users Leave» (Как: очищать файлы после ухода пользователя) по адресу http://msdn2.microsoft.com/en-us/library/msl94958(VS.80).aspx.

Больше информации о команде Workspace можно найти в статье «Workspace Command» (Команда Workspace) по адресу http://msdn2.microsoft.com/en-us/librarv/y901w7se(VS.80).aspx.

Подробнее о поиске ожидающих регистрации изменений рассказывает статья «How do I tell who has files checked out or locked?» (Как я узнаю, кто редактирует или заблокировал файлы?), которую можно найти по адресу http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/24/3125.aspx.

Как предоставить права доступа непосредственно в дереве исходного кода

Чтобы задать права доступа к файлу или папке в каталоге исходного кода, щелкните правой кнопкой мыши файл или папку в Source Control Explorer, выберите Properties, щелкните вкладку Security, выберите пользователя или группу, для которых необходимо изменить права доступа, и можете редактировать их. Также права доступа можно задать, используя ключ Permission с утилитой командной строки tf.exe для системы контроля версий.

Хотя права доступа могут применяться к отдельным папкам и файлам, по умолчанию в дереве исходного кода происходит наследование прав доступа от папки проекта. Разработчики, являющиеся членами группы Project\Contributors приложения, смогут читать исходные файлы, изымать их для регистрации, регистрировать изменения в них, маркировать метками и блокировать. Если требуется предоставить ограниченный доступ к подмножеству папок или исходных файлов группового проекта — например, чтобы разработчик мог работать только с определенными исходными файлами группового проекта — можно задать права доступа на уровне папки или файла.

Дополнительные источники

Больше информации о предоставлении прав доступа можно найти в статье «Team Foundation Server Default Groups, Permissions, and Roles» на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/ms253077.aspx.

О предоставлении прав доступа подробнее рассказывается в статье «Source Control Security Rights and Permissions» по адресу http://msdn2.microsoft.com/en-us/library/msl81761.aspx.

Команда tf permission подробно рассматривается в статье «Permission Command» (Команда Permission) по адресу http://msdn2.microsoft.com/en-us/library/0dsd05ft(VS.80).aspx.

Как перенести Team Foundation Version Control на другой сервер

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

Team Foundation Server поддерживает следующие три типа переносов:

• Резервное копирование и восстановление — Этот тип переноса используется для переноса Team Foundation Server на новый компьютер. Как это делается с подробным разбором всех шагов, рассказывается в статье «How to: Move Your Team Foundation Server from One Hardware Configuration to Another» (Как: перенести Team Foundation Server с одной конфигурации оборудования на другую) по адресу http://msdn2.microsoft.com/en-us/library/ms404869(VS.80).aspx.

• Смена среды — Этот тип переноса используется, когда требуется перенести Team Foundation Server в новый домен или рабочую группу. Подробный разбор этой процедуры по шагам представлен в статье «How to: Move Your Team Foundation Server from One Environment to Another» (Как: перенести Team Foundation Server из одной среды в другую) по адресу http://msdn2.microsoft.com/en-us/library/ms404883(VS.80).aspx.

• От одного сервера к двум серверам — Этот тип переноса используется для перехода от развертывания на одном сервере к развертыванию на двух серверах. Этот вопрос подробно рассмотрен в статье «How to: Move from a Single-Server to a Dual-Server Deployment» (Как: перейти от развертывания на одном сервере к развертыванию на двух серверах) по адресу http://msdn2.microsoft.com/en-us/library/ms404854(VS.80).aspx.

При переносе Team Foundation Server следует помнить следующее:

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

После изменения имени сервера все связанные с запросами документы Microsoft Office не будут работать. Эти документы создаются автоматически в момент создания проекта в папке Documents и связаны с сервером, для которого были созданы.

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

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

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

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

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

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

Дополнительные источники

Подробную информацию о переносе TFS можно найти по адресу http://msdn2.microsoft.com/en-us/library/ms404879(VS.80).aspx.

Ветвление / маркирование метками / слияние

• Как использовать метки

• Как выполнять ветвление

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

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

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

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

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

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

• Как использовать ветвление для изоляции внешних зависимостей

• Как вывести из обращения старую версию

• Как выполнять слияние

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

• Как разрешать конфликты при слиянии

Как использовать метки

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

Чтобы применить метку к файлу или папке

1. Щелкните правой кнопкой мыши файл или папку в Source Control Explorer и выберите Apply Label (Применить метку).

2. В диалоговом окне Choose Item Version (Выбрать версию элемента) внесите поправки в свой выбор файла или папки, выберите версию файла или папки, которые хотите маркировать меткой, и затем щелкните OK, чтобы применить метку.

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

Метки являются маркерами, которые можно применять одновременно только к одной версии файла или папки.

К версии файла или папки можно применять несколько меток.

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

Метки являются объектами, не имеющими версий, и с ними не ассоциирована история версий.

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

Team Build автоматически присваивает метку набору файлов, ассоциированному с каждой создаваемой сборкой.

Метки не применяются к удаленным элементам; это означает, что при слиянии по метке удаленные файлы не восстанавливаются.

Чтобы найти существующую метку

1. В меню File выберите Source Control, выберите Label, щелкните Find Label и перейдите к метке.

2. Найдя метку, ее можно изменять или удалять с помощью диалогового окна Find Label.

Дополнительные источники

Подробнее об использовании меток рассказывает статья «Working with Labels» по адресу http://msdn2.microsoft.com/en-us/library/msl81439(VS.80).aspx.

Подробнее о применении меток рассказывает статья «How to: Apply Labels» по адресу http://msdn2.microsoft.com/en-us/librarv/msl81440(VS.80).aspx.

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

Создать ветвь можно из Source Control Explorer или из командной строки, используя команду tf branch.

Чтобы выполнить ветвление в Source Control Explorer, щелкните правой кнопкой мыши папку верхнего уровня, содержащую исходный код вашего проекта, щелкните Branch (Ветвление) и укажите местоположение целевой папки. Задавайте осмысленное имя

папки, из которого понятно назначение ветви, например, MyProject_Release1.0_Branch.

Чтобы выполнить ветвление из командной строки, используется Visual Studio 2005 Command Prompt и команда tf branch; например:

tf branch C:\MyProject $/MyProjectReleasel.0Branch

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

Дополнительные источники

Введение в ветвление и слияние предлагает материал «Branching and Merging Primer», который можно найти по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.

Ветвление подробно рассматривается в статье «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81425(VS.80).aspx.

Слияние подробно рассматривается в статье «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

Дополнительную информацию о ветвлении и слиянии в Visual Studio 2005 представляет статья «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/msl81423(VS.80).aspx.

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

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

Обычные сценария ветвления:

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

• Ветвление для обслуживания — Ветвление для обслуживания ранее выпущенной сборки.

• Ветвление для разработки функциональной возможности — Ветвление для изолированной разработки функциональной возможности, введение которой может привести к дестабилизации всего проекта.

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

Не следует использовать ветвление, если в нем нет крайней необходимости. Ветвление требует дополнительного обслуживания каталога исходного кода и выполнения задач по слиянию. Для большинства групп разработки, которые занимаются созданием бизнес-приложений и имеют короткие циклы выпуска новых версий (например, специализированных бизнес-приложений1), ветвления не требуется. Группам разработки, реализующим более длинные циклы выпуска, таким как Независимые производители ПО (Independent Software Vendors, ISV), которые создают «коробочные» приложения, скорее всего, придется прибегнуть к ветвлению в своем процессе разработки.

Дополнительные источники

Введение в ветвление и слияние предлагает материал «Branching and Merging Primer», который можно найти по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.

Ветвление подробно рассматривается в статье «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81425(VS.80).aspx.

Слияние подробно рассматривается в статье «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

Дополнительную информацию о ветвлении и слиянии в Visual Studio 2005 представляет статья «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/msl81423(VS.80).aspx.

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

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

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

• Main — Ветвь интеграции о Source о Other Asset Folders

1Line-of-Business [LOB] applications (прим. переводчика)

• Releases — Контейнер ветвей выпускаемых версий о Release 1 — Выпускаемая версия ¦ Source

При работе с ветвью Release необходимо помнить следующее:

• Когда выполнять ветвление — Если вы готовы к выпуску версии, сведите все в ветвь Main и создайте ветвь Release, которая может использоваться для стабилизации приложения перед выпуском версии.

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

• Права доступа при работе с ветвями:

о Перед выпуском версии — предоставьте права на чтение/запись всем разработчикам.

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

• Частота сборки в ветви — сборки выполняются по требованию.

• Тестирование в ветви — прекращается после выпуска версии.

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

Дополнительные источники

Введение в ветвление и слияние предлагает материал «Branching and Merging Primer», который можно найти по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.

Ветвление подробно рассматривается в статье «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81425(VS.80).aspx.

Слияние подробно рассматривается в статье «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

Дополнительную информацию о ветвлении и слиянии в Visual Studio 2005 представляет статья «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/msl81423(VS.80).aspx.

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

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

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

• Main — Ветвь интеграции

о Source

о Other Asset Folders

• Releases — Контейнер ветвей выпускаемых версий

о Release 1 — Ветвь обслуживания

¦ Source

¦ Other Asset Folders

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

• Когда выполнять ветвление — После выпуска версии ее обслуживание обеспечивается в ветви, находящейся в папке Releases.

• Когда не стоит прибегать к ветвлению — Если выпущенную версию не надо обслуживать, можно просто маркировать меткой старую выпущенную сборку и продолжать работу в главной ветви.

• Права доступа при работе с ветвями — Разработчики, работающие над исправлениями в уже выпущенной версии, должны иметь права на чтение/запись, все остальные — права только на чтение.

• Частота сборки в ветви — Сборки выполняются по требованию.

• Тестирование в ветви — Прекращается после выпуска версии.

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

Дополнительные источники

Введение в ветвление и слияние предлагает материал «Branching and Merging Primer», который можно найти по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.

Ветвление подробно рассматривается в статье «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81425(VS.80).aspx.

Слияние подробно рассматривается в статье «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

Дополнительную информацию о ветвлении и слиянии в Visual Studio 2005 представляет статья «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/msl81423(VS.80).aspx.

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

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

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

• Development — Ветвь разработки

о Source

• Main — Ветвь интеграции

о Source

о Other Assets folders

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

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

• Когда не стоит прибегать к ветвлению — Если создаются только сборки в процессе непрерывной интеграции (CI) или ежедневные сборки уже предсказуемо стабильны, возможно, нет необходимости нести дополнительные издержки по содержанию ветви интеграции

• Права доступа при работе с ветвями:

о Разработчики, ответственные за слияние и интеграцию, должны иметь право на чтение/запись в ветвь Main, но все остальные — только право на чтение.

о Право на чтение/запись в ветвь Development должно быть у всех.

• Частота сборки в ветви:

о Ежедневные сборки для ветви Main.

о Сборки в процессе непрерывной интеграции для ветви Development.

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

о Для ветви Main выполняется интеграционное тестирование, тестирование производительности и безопасности.

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

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

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

Дополнительные источники

Введение в ветвление и слияние предлагает материал «Branching and Merging Primer», который можно найти по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.

Ветвление подробно рассматривается в статье «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81425(VS.80).aspx.

Слияние подробно рассматривается в статье «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

Дополнительную информацию о ветвлении и слиянии в Visual Studio 2005 представляет статья «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/msl81423(VS.80).aspx.

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

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

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

Development — Контейнер ветвей функциональных возможностей

о Feature A — Ветвь функциональной возможности

¦ Source

о Feature B — Ветвь функциональной возможности

¦ Source

о Feature C — Ветвь функциональной возможности

¦ Source

Main — Ветвь интеграции

о Source

о Other Asset Folders

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

• Когда выполнять ветвление — Часто группы разработки функциональных возможностей работают над одними и теми же файлами, что увеличивает вероятность сбоев при сборке и конфликтов при регистрации изменений. При возникновении таких проблем используйте отдельную ветвь для каждой функциональной возможности, чтобы изолировать работу над ней. Такие ветви могут создаваться от ветви Main для небольших групп и от ветвей Team (Группа) для больших групп.

• Когда не стоит прибегать к ветвлению — Если выполняются только C1-сборки или ежедневные сборки уже стали предсказуемо стабильными, возможно, нет смысла нести дополнительные издержки, связанные с существованием ветвей Feature.

Права доступа при работе с ветвями – Разработчики должны иметь право на чтение/запись в ветвь функциональной возможности, все остальные – право только на чтение.

Частота сборки в ветви – Для ветви выполняется сборка в процессе непрерывной интеграции.

Тестирование в ветви – Выполняется функциональное тестирование и тестирование для получения быстрой обратной связи.

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

Дополнительные источники

Введение в ветвление и слияние предлагает материал «Branching and Merging Primer», который можно найти по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.

Ветвление подробно рассматривается в статье «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81425(VS.80).aspx.

Слияние подробно рассматривается в статье «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

Дополнительную информацию о ветвлении и слиянии в Visual Studio 2005 представляет статья «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/msl81423(VS.80).aspx.

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

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

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

Development — Контейнер ветвей группы

о Team 1 — Ветвь группы

¦ Source

о Team 2 — Ветвь группы

¦ Source

Main — Ветвь интеграции

о Source

о Other Asset Folders

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

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

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

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

Частота сборки в ветви – Для ветви выполняется сборка в процессе непрерывной интеграции.

Тестирование в ветви – Выполняется функциональное тестирование и тестирование для получения быстрой обратной связи.

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

Дополнительные источники

Введение в ветвление и слияние предлагает материал «Branching and Merging Primer», который можно найти по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.

Ветвление подробно рассматривается в статье «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81425(VS.80).aspx.

Слияние подробно рассматривается в статье «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

Дополнительную информацию о ветвлении и слиянии в Visual Studio 2005 представляет статья «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/msl81423(VS.80).aspx.

Как использовать ветвление для изоляции внешних зависимостей

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

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

• External — Ветвь внешней зависимости

о Source

• Main — Ветвь интеграции

o Source

o Other Asset Folders

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

• Когда выполнять ветвление — Если имеются внешние зависимости, которые могут обусловить приводящие к сбоям изменениям в проекте. Если зависимости существенно меняют интерфейс или логику, что будет иметь влияние на ваш код, создайте ветвь External, чтобы изолировать эти изменения.

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

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

• Частота сборки в ветви — Сборки выполняются по требованию.

• Тестирование в ветви — Интеграционное тестирование.

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

Дополнительные источники

Введение в ветвление и слияние предлагает материал «Branching and Merging Primer», который можно найти по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.

Ветвление подробно рассматривается в статье «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81425(VS.80).aspx.

Слияние подробно рассматривается в статье «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

Дополнительную информацию о ветвлении и слиянии в Visual Studio 2005 представляет статья «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/msl81423(VS.80).aspx.

Как вывести из обращения старую версию

Когда срок существования ветви Release в папке Releases настолько велик, что больше нет необходимости ее поддерживать, создайте папку Safe Keeping (Архив) для хранения старых версий. Вот пример структуры ветвления после создания папки Safe Keeping:

• Main — Ветвь интеграции

о Source

о Other Asset Folders

• Releases — Контейнер ветвей выпускаемых версий

о Release 2 — Ветвь обслуживания

¦ Source

¦ Other Asset Folders

• Safe Keeping — Контейнер ветвей архивного хранения

о Release 1 — Ветвь архивного хранения

¦ Source

¦ Other Asset Folders

Цель переноса ветви из папки Releases в папку Safe Keeping — наведение порядка в папке Releases без уничтожения старых версий. Это не новая ветвь, а, скорее, перенос старой ветви в новую папку.

Дополнительные источники

Введение в ветвление и слияние предлагает материал «Branching and Merging Primer», который можно найти по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.

Ветвление подробно рассматривается в статье «How to: Branch Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81425(VS.80).aspx.

Слияние подробно рассматривается в статье «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

Дополнительную информацию о ветвлении и слиянии в Visual Studio 2005 представляет статья «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/msl81423(VS.80).aspx.

Как выполнять слияние

Перенос изменений из одной ветви в другую осуществляется с помощью команды merge. Для слияния могут использоваться функциональные возможности слияния Source Control Explorer или инструмент командной строки tf merge. Слияние может выполняться по пакету изменений, метке, дате или версии. Чтобы начать слияние, щелкните правой кнопкой мыши ветвь в Source Control Explorer и выберите Merge. Source Control Merge Wizard (Мастер слияния системы контроля версий) предоставляет возможность выбирать целевую ветвь, с которой выполняется слияние.

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

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

Слияние вдоль по иерархии — от родителя к потомку или от потомка к родителю — сопровождается меньшим количеством конфликтов, чем слияние поперек иерархии.

В основе иерархии ветвей лежат ветвь-родитель и ветвь-потомок, и эта иерархия может отличаться от физической структуры исходного кода, представленной в Source Control Explorer; например:

о Физическая структура:

¦ Development —Ветвь разработки

¦ Main — Ветвь интеграции

¦ Releases — Контейнер ветвей выпускаемых версий

• Release 1 — Выпускаемая версия о Логическая структура:

¦ Main

• Development

• Release 1

Дополнительные источники

Больше информации о слиянии можно найти в статье «Understanding Merging» (Понимание слияния) по адресу http://msdn2.microsoft.com/en-us/library/msl81427(VS.80).aspx.

Описание слияния с пошаговым разбором всей процедуры представлено в статье «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

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

Для выполнения слияния без общей родительской версии используется Visual Studio 2005 Command Prompt и команда tf merge /baseless.

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

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

Пример

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

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

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

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

Дополнительные источники

Синтаксис команды merge описывается в статье «Merge Command» (Команда Merge) по адресу http://msdn2.microsoft.com/en-us/librarv/bd6dxhfy(VS.80).aspx.

Больше информации о слиянии можно найти в статье «Understanding Merging» по адресу http://msdn2.microsoft.com/en-us/library/msl81427(VS.80).aspx.

Описание слияния с пошаговым разбором всей процедуры представлено в статье «How to: Merge Files and Folders» по адресу http://msdn2.microsoft.com/en-us/library/msl81428(VS.80).aspx.

Как разрешать конфликты при слиянии

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

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

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

• Конфликт имен файлов — В одном каталоге существует два или более элементов под одним именем.

• Перезапись локальной версии файла — Возникает только при выполнении операции get при попытке перезаписать локальный доступный для редактирования файл.

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

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

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

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

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

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

Дополнительные источники

Больше информации о разрешении конфликтов представлено в статье «How to: Resolve Conflicts» (Как: разрешать конфликты), которую можно найти по адресу http://msdn2.microsoft.com/en-us/library/msl81433(VS.80).aspx.

Сборки

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

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

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

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

Дополнительные источники

Скачать предлагаемый Microsoft Веб-сервис для запуска процесса сборки можно по адресу http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi.

Регистрации изменений и политики регистрации изменений

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

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

• Как переопределить политику регистрации изменений

• Как отменить регистрацию изменений

• Как разрешить конфликт

• Как избегать конфликтов

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

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

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

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

Маркирование пакета изменений меткой.

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

Изменение данных пакета изменений.

Откат изменений пакета изменений.

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

1. В меню Visual Studio View (Просмотр) выберите Other Windows (Другие окна) и щелкните Pending Changes (Ожидающие регистрации изменения).

2. Введите комментарий, отражающий суть изменений.

3. Щелкните значок Work Items, чтобы вывести на экран список ассоциированных рабочих элементов.

4. Обновите ассоциированные рабочие элементы, выбирая их и определяя действие при регистрации изменения, Associate (Ассоциировать) или Resolve (Решить) (если регистрация означает переход рабочего элемента в статус «Решен»).

5. Щелкните Check In, чтобы зарегистрировать пакет изменений на сервере системы контроля версий.

Чтобы маркировать пакет изменений меткой

1. В Visual Studio в Source Control Explorer щелкните правой кнопкой мыши папку своего Team Project и выберите Apply Label.

2. В выпадающем списке Version (Версия) выберите Changeset (Пакет изменений), введите Changeset number (Номер пакета изменений) и щелкните OK.

3. В диалоговом окне Apply Label введите имя метки и комментарий, затем щелкните OK.

Чтобы просмотреть данные пакета изменений

Используйте команду tf changeset.

По следующей команде на экран будет выведено диалоговое окно Details for Changeset (Данные пакета изменений) с данными пакета изменений номер 1234:

tf changeset 1234

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

Чтобы изменить данные пакета изменений

Чтобы изменить комментарии и/или записи, ассоциированные с пакетом изменений, используйте команду tf changeset.

По следующей команде будет отображено диалоговое окно Details for Changeset для пакета изменений 1234 и обновлено поле отображаемого комментария:

tf changeset /comment:»Этот комментарий намного лучше предыдущего.» 1234

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

tf changeset /notes:» Code Reviewer»=»C Дэвис»;»Security Reviewer»=»0 Смит» 1234

Откат пакета изменений и удаление изменения с сервера системы контроля версий выполняется с помощью инструмента Team Foundation Power Tool.

Чтобы выполнить откат пакета изменений, используя Team Foundation Power Tool

Используйте команду Tfpt rollback.

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

TFPT rollback /changeset:1234

По этой команде на экран выводится окно Roll Back Changeset (Отменить пакет изменений). Можно выбрать файлы, включенные в пакет изменений, и выполнить откат изменений в них.

Дополнительные источники

Подробнее о команде tf changeset рассказывает статья «Changeset Command» (Команда Changeset) по адресу http://msdn2.microsoft.com/en-us/library/w51xa47k(VS.80).aspx.

Больше информации об извлечении пакетов изменений представлено в статье «How to: Retrieve Old Versions of Files from Changesets» (Как: извлекать старые версии файлов из пакетов изменений) по адресу http://msdn2.microsoft.com/en-us/library/msl81416(VS.80).aspx.

Скачать Team Foundation Power Tool (TFPT) с сайта MSDN можно по адресу http://www.microsoft.com/downloads/details.aspx?FamilVID=7324C3DB-658D-441B-8522-689C557D0A79&displaylang=en.

О Team Foundation Power Tool подробнее рассказывает статья «Power Toy: tfptexe» по адресу http://blogs.msdn.com/buckh/archive/2005/ll/16/493401.aspx.

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

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

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

• Анализ кода — Требует выполнение анализа кода перед регистрацией изменений в системе контроля версий.

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

• Рабочие элементы — Требует, чтобы с регистрацией изменений был ассоциирован один или более рабочих элементов.

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

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

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

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

2. Выберите Check-in Policy и щелкните Add.

3. В списке Check-in policy выберите Code Analysis и щелкните OK.

4. Выбрав соответствующий флажок, определите необходимый тип анализа кода. При выборе Enforce Code Analysis For Managed Code, выберите необходимые правила из списка Rule settings for Managed Code Analysis (Правила для анализа управляемого кода).

5. Дважды щелкните OK.

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

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

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

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

Пользователи не используют определенные директивы pragma в C# для подавления предупреждений об отсутствии XML-документации.

Гарантировать, что в проекте включена опция формирования XML-документации во время компиляции.

Для создания специальных подключаемых модулей политики, которые будут отображаться в диалоговом окне Add Checkin Policy, используйте возможности расширения, предоставляемые в Visual Studio Team Foundation Server Software Development Kit (SDK).

Дополнительные источники

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

регистрации изменений в Visual Studio Team Foundation Server» данного руководства.

Как настраивать политику регистрации изменений рассказывает статья «Walkthrough: Customizing Check-in Policies and Notes» по адресу http://msdn2.microsoft.com/en-us/library/msl81281(VS.80).aspx.

Увидеть пример кода, который не допустит регистрации файлов, содержащих определенные шаблоны, можно в статье «Checkin Policy to Disallow Certain Patterns» по адресу http://blogs.msdn.com/imanning/archive/2006/02/02/523125.aspx.

Увидеть пример кода, который требует обязательного ввода комментариев при регистрации изменений, можно в статье «Sample Checkin Policy: Make Sure the Comment Isn’t Empty» по адресу http://blogs.msdn.com/imanning/archive/2006/01/21/515858.aspx.

Как добавить новую политику регистрации изменений, рассказывается в статье «I’ve Made a New Check-In Policy! How Do I Add It?», которую можно найти по адресу http://blogs.msdn.com/imanning/archive/2006/02/07/526778.aspx.

Больше информации об использовании инструментов анализа кода можно найти в статье «Guidelines for Using Code Analysis Tools» по адресу http://msdn2.microsoft.com/en-us/library/msl82023(VS.80).aspx.

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

Чтобы переопределить политику регистрации изменений, установите флажок Override policy failure and continue check-in (Игнорировать нарушение политики и продолжить регистрацию изменений) в диалоговом окне Policy Failure (Нарушение политики). Любой пользователь, имеющий право регистрировать изменения в файлах, может переопределять политику регистрации изменений.

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

Дополнительные источники

Более подробно о переопределении политики регистрации изменений рассказывается в статье «How to: Override a Check-in Policy» по адресу http://msdn2.microsoft.com/en-us/library/ms245460(VS.80).aspx.

Подробнее о Team Foundation Eventing Service рассказывает статья «Eventing Service» по адресу http://msdn2.microsoft.com/en-us/library/bbl30154(vs.80).aspx.

Как выявлять переопределения политики с помощью модели TFS Object Model, а не обработки событий, рассказывается в сообщении блога Джеймса Маннинга на сайте MSDN (http://blogs.msdn.com/imanning/archive/2005/ll/04/489193.aspx).

Как отменить регистрацию изменений

Отменить зарегистрированные изменения в файле можно с помощью команды rollback Team Foundation Power Tools (TFPT), которая возвратит файл к предыдущей версии. Команда rollback позволяет выполнить откат как сразу всего пакета изменений, так и

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

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

1. Выполните следующую команду из командного окна, которое включает папку \program files\microsoft team foundation server power tools в переменной окружения PATH:

TFPT rollback filename.cs

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

TFPT rollback filename.cs /changeset:54

2. При выполнении команды rollback рабочее пространство должно гарантированно содержать только последние версии файлов. Щелкните Yes в ответ на сообщение Roll Back Changeset. В этот момент ваше рабочее пространство будет обновлено и получит последние версии файлов с сервера.

3. Если в командной строке не указан номер пакета изменений, на экран выводится диалоговое окно Find Changeset (Поиск пакета изменений). Введите критерий поиска или просто щелкните Find и выберите пакет, содержащий изменение, регистрацию которого вы хотите отменить. После этого щелкните Roll Back (Откат).

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

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

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

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

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

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

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

• Разрешение конфликтов — Если необходимо выполнять слияние, используйте окно слияния. Чтобы осуществить слияние, выберите элемент и щелкните Merge. Сначала делается попытка выполнить слияние автоматически. Если это не удается, запускается инструмент слияния для разрешения конфликтов. По нажатию кнопки Auto-Merge All (Полное автоматическое слияние) делаются попытки автоматического слияния каждого из элементов списка слияния, но инструмент слияния не вызывается.

Дополнительные источники

Скачать инструмент TFPT из MSDN можно по адресу http://www.microsoft.com/downloads/details.aspx?FamilVID=7324C3DB-658D-441B-8522-689C557D0A79&displaylang=en.

Узнать больше о TFPT можно в статье «Power Toy: tfptexe» по адресу http://blogs.msdn.com/buckh/archive/2005/ll/16/493401.aspx.

Как разрешить конфликт

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

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

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

• Конфликт имен файлов — В одном каталоге существует два или более элементов под одним именем.

• Перезапись локальной версии файла — Возникает только при выполнении операции get при попытке перезаписать локальный доступный для редактирования файл.

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

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

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

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

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

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

Дополнительные источники

Больше информации о разрешении конфликтов представлено в статье «How to: Resolve Conflicts», которую можно найти по адресу http://msdn2.microsoft.com/en-us/library/msl81433(VS.80).aspx.

Как избегать конфликтов

Чтобы избежать конфликтов:

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

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

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

Для просмотра ожидающих регистрации изменений

1. В Source Control Explorer щелкните правой кнопкой мыши решение, проект, папку или файл, для которого хотите просмотреть ожидающие регистрации изменения.

2. Выберите View Pending Changes.

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

tf status /format:detailed /user:*

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

Дополнительные источники

Подробнее о том, как просматривать ожидающие регистрации изменения в вашем рабочем пространстве, рассказывается в статье «How to: View and Manage All Pending Changes in Your Workspace» по адресу http://msdn2.microsoft.com/en-us/library/msl81400(VS.80).aspx.

Подробнее о том, как просматривать ожидающие регистрации изменения в других рабочих пространствах, рассказывается в статье «How to: View Pending Changes in Other Workspaces» по адресу http://msdn2.microsoft.com/en-us/library/msl81401(VS.80).aspx.

Команда tf status подробно рассматривается в статье «Status Command» (Команда Status) по адресу http://msdn2.microsoft.com/en-us/library/9s5ae285(VS.80).aspx.

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

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

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

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

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

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

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

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

Примечание: Эти интерфейсы предоставляет класс PolicyBase. Альтернативный вариант реализации интерфейсов IPolicyDefinition и IPolicyEvaluation — унаследовать класс от PolicyBase.

Дополнительные источники

Подробнее о создании и использовании специальной политики регистрации изменений рассказывается в разделе «Как: создавать специальные политики регистрации изменений в Visual Studio Team Foundation Server» данного руководства.

Как настраивать политику регистрации изменений рассказывает статья «Walkthrough: Customizing Check-in Policies and Notes» по адресу http://msdn2.microsoft.com/en-us/library/msl81281(VS.80).aspx.

Увидеть пример кода, который не допустит регистрации файлов, содержащих определенные шаблоны, можно в статье «Checkin Policy to Disallow Certain Patterns» по адресу http://blogs.msdn.com/imanning/archive/2006/02/02/523125.aspx.

Увидеть пример кода, который требует обязательного ввода комментариев при регистрации изменений, можно в статье «Sample Checkin Policy: Make Sure the Comment Isn’t Empty» по адресу http://blogs.msdn.com/imanning/archive/2006/01/21/515858.aspx.

Как добавить новую политику регистрации изменений, рассказывается в статье «I’ve Made a New Check-In Policy! How Do I Add It?», которую можно найти по адресу http://blogs.msdn.com/imanning/archive/2006/02/07/526778.aspx.

Больше информации об использовании инструментов анализа кода можно найти в статье «Guidelines for Using Code Analysis Tools» по адресу http://msdn2.microsoft.com/en-us/library/msl82023(VS.80).aspx.

Подробнее о создании новой политики рассказывается в статье «Policy Plug-ins» (Подключаемые модули политики) по адресу http://msdn2.microsoft.com/en-us/library/bbl30343(VS.80).aspx.

Изъятие, получение и блокировка

• Как синхронизировать свой компьютер с TFS

• Как подготовить файл к редактированию

Как синхронизировать свой компьютер с TFS

Синхронизация с сервером контроля версий выполняется с помощью команды tf get. Так можно быстро гарантировать, что вы работаете синхронно с вашей группой, и на вашем компьютере находятся копии последних версий разрабатываемых файлов. Чтобы загрузить все файлы, не только те, версии которых надо обновить, выполните из окна командной строки Visual Studio 2005 следующую команду:

tf get /all

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

tf get /force

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

Чтобы выполнить ту же операцию из Visual Studio:

1. В Team Explorer щелкните двойным щелчком папку Source Control, щелкните правой кнопкой мыши ваш сервер или групповой проект и затем щелкните Get Specific Version (Получить конкретную версию).

2. Выберите Overwrite writable files that are not checked out (Перезаписать доступные для записи файлы, которые не изъяты для редактирования) и Force get of file versions already in workspace (Принудительное получение версий файлов, находящихся в рабочем пространстве).

3. В выпадающем списке Type убедитесь, что выбрана запись Latest Version (Последняя версия), и щелкните Get.

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

Дополнительные источники

Команда get подробно рассматривается в статье «Get Command» по адресу http://msdn2.microsoft.com/pt-br/librarv/fx7sdeyf(VS.80).aspx.

Как подготовить файл к редактированию

Чтобы подготовить файл к редактированию, необходимо сначала получить его последнюю версию из системы контроля версий Team Foundation Server и затем изъять ее для редактирования.

Чтобы подготовить файл к редактированию

1. В Source Control Explorer выберите файл, щелкните правой кнопкой мыши и выберите Get Latest Version.

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

2. Щелкните файл правой кнопкой мыши и выберите Check Out for Edit.

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

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

Примечание: По команде get latest version не происходит изъятия файла для редактирования и в ходе операции check out for edit не выполняется операция get. Оба этих действия необходимо производить отдельно. В этом поведение Visual Studio 2005 отличается от поведения Microsoft Visual SourceSafe.

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

Изъятие версии файла для редактирования из системы контроля версий одновременно несколькими пользователями (Тип блокировки: None) позволяет избежать задержек в процессе разработки из-за невозможности работы с файлами для других участников группы.

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

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

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

Дополнительные источники

Команда checkout более подробно рассматривается в статье «Checkout and Edit Commands» (Команды для изъятия и редактирования) по адресу http://msdn2.microsoft.com/pt-br/librarv/lyft8zkw(VS.80).aspx.

Совместное использование кода

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

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

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

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

У групп есть два варианта работы с совместно используемым исходным кодом:

1. Включить код из совместно используемого каталога.

2. Создать ветвь совместно используемого кода в своем проекте.

1. Включение кода из совместно используемого каталога.

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

Преимущество такого подхода в том, что изменения в совместно используемом коде подхватываются при каждом получении самой последней версии исходного кода в рабочее пространство. Например, имеется два групповых проекта, Client (Клиент) и Shared Code (Совместно используемый код), из которых Shared Code — контейнер совместно используемого исходного кода. Чтобы совместно использовать исходный код у этих проектов будет общий каталог на жестком диске клиента:

c:\TestProject\Client

c:\TestProject\Shared Code

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

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

$/Client c:\TestProject\Client

$/Shared Code c:\TestProject\Shared Code

Более подробная информация представлена в статье «Working with multiple team projects in Team Build» по адресу http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx.

2. Создание ветви совместно используемого кода.

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

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

Например, имеется два групповых проекта, Client и Shared Code, из которых Shared Code – контейнер совместно используемого исходного кода. Чтобы создать ветвь совместно используемого кода, выполните следующее:

a. В Source Control Explorer щелкните правой кнопкой мыши корневую папку проекта Shared Code.

b. Выберите опцию Branch.

c. В диалоговом окне Branch в качестве Target (Цель) задайте корневую папку группового проекта Client и щелкните OK.

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

Дополнительные источники

Более подробная информация представлена в статье «Working with multiple team projects in Team Build» по адресу http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx.

Введение в ветвление и слияние предлагает материал «Branching and Merging Primer», который можно найти по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.

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

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

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

Существуют следующие варианты хранения двоичных файлов:

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

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

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

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

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

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

1. В Source Control Explorer щелкните правой кнопкой мыши корневую папку проекта Shared Binaries (Совместно используемые двоичные файлы).

2. Выберите опцию Branch.

3. В диалоговом окне Branch в качестве Target задайте корневую папку группового проекта Client и щелкните OK.

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

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

• Main

о Source — Содержит код проекта

о Lib — Содержит совместно используемые двоичные файлы

Дополнительные источники

Более подробная информация представлена в статье «Working with multiple team projects in Team Build» по адресу http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx.

Введение в ветвление и слияние предлагает материал «Branching and Merging Primer», который можно найти по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.

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

Зависимости

• Как работать со ссылками на Веб-сервисы

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

Как работать со ссылками на Веб-сервисы

Как правило, Uniform Resource Locator (URL) Веб-сервиса в среде производственной эксплуатации отличается от ссылки, используемой в средах разработки и тестирования. Чтобы облегчить работу с URL Веб-сервиса, его значение следует задавать в пользовательском конфигурационном файле. Тогда любой разработчик и тестер сможет менять его, не затрагивая основной файл App.config. Для этого свойству URL Behavior ссылки на Веб-сервис задается значение Dynamic. Храните URL Веб-сервиса в пользовательском конфигурационном файле и используйте ссылки на него.

По умолчанию при добавлении Веб-ссылки Visual Studio задает этому свойству значение Dynamic.

Чтобы проверить значение свойства URL Behavior

1. В Solution Explorer разверните список Веб-ссылок.

2. Пройдитесь по всем Веб-ссылкам списка.

3. Для каждой Веб-ссылки проверьте значение свойства URL Behavior (оно должно быть Dynamic).

Чтобы задать URL Веб-сервиса в пользовательском конфигурационном файле

Когда Веб-ссылка задается впервые, файл App.config выглядит следующим образом:

<configuration>

<configSections>

<sectionGroup name=»applicationSettings» type=»System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ >

<section name=» SomeService.Properties.Settings» type=»System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ requirePermission=»false» /> </sectionGroup> </configSections> <applicationSettings>

<YourProject.Properties.Settings>

<setting name=»SomeService_ localhost _Service» serializeAs=»String»>

<value>http://localhost/someservice/Service.asmx</value> </setting> </ YourProject.Properties.Settings> </applicationSettings> </configuration>

В данном файле имеется новая секция конфигурации, в которой содержится адрес Веб-сервиса, обнаруженный Visual Studio при формировании этого прокси-класса.

Чтобы создать файл User.config

1. В Solution Explorer щелкните правой кнопкой мыши проект, содержащий ссылку на Веб-сервис, выберите Add и щелкните New Item.

2. Выберите Application Configuration File, измените имя на User.config и щелкните Add.

3. Скопируйте настройки элемента <YourProject.Properties.Settings> из конфигурационного файла своего приложения (App.config) в файл User.config. Этот файл должен содержать только элемент, который выносится из основного конфигурационного файла приложения. Удалите директиву <?xml> и элемент

<configuration>, если они есть, как показано в следующем примере:

<YourProject.Properties.Settings>

<setting name=»SomeService_localhost_Service» serializeAs=»String»> <value>http://localhost/someservice/Service.asmx</value>

</setting> </YourProject.Properties.Settings>

4. В Solution Explorer щелкните правой кнопкой мыши файл User.config, выберите Properties и задайте свойству Copy To Output Directory значение Copy if newer.

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

Чтобы файл App.config использовал файл User.config при организации доступа к URL Веб-сервиса, его необходимо обновить следующим образом

1. Добавить атрибут configSource=«user.config» в элемент <YourProject.Properties.Settings> главного конфигурационного файла приложения.

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

2. Удалить содержимое элемента <YourProject.Properties.Settings>.

Теперь App.config должен выглядеть следующим образом:

<?xml version=»1.0″ encoding=»utf-8″ ?> <configuration>

<configSections>

<sectionGroup name=»applicationSettings» type=»System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ >

<section name=»SomeService.Properties.Settings» type=»System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ requirePermission=»false» /> </sectionGroup> </configSections> <applicationSettings>

<YourProject.Properties.Settings configSource=»user.config»> </YourProject.Properties.Settings> </applicationSettings> </configuration>

В предыдущем примере YourProject – имя проекта, содержащего ссылку на Веб-сервис. Убедитесь, что элемент <SomeService.Properties.Service> файла App.config пуст.

Важно:

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

определенным URL, используя собственные файлы User.config. Чтобы предотвратить добавление файла User.config в систему контроля версий, при первой регистрации изменений в файле необходимо убрать флажок напротив User.config. После этого можно щелкнуть правой кнопкой мыши файл в Solution Explorer и выбрать опцию Undo Pending Changes. Тогда файл гарантированно не будет подлежать контролю версий.

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

Храните глобальный файл User.config в системе контроля версий. Он может содержать только корневой элемент (без элемента <setting>) или может определять местоположение Веб-сервиса по умолчанию. Наличие файла User.config обеспечивает возможность работы системы конфигурации.

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

Дополнительные источники

Больше информации можно найти в статье «Web Projects and Source Control Integration in Visual Studio .NET» (Веб-проекты и интеграция с системой контроля версий в Visual Studio .NET) по адресу http://msdn2.microsoft.com/en-US/library/aa290068(VS.71).aspx.

Класс ApplicationSettingsGroup (Группа настроек приложения) подробно рассматривается в статье «ApplicationSettingsGroup Class» (Класс ApplicationSettingsGroup) по адресу http://msdn2.microsoft.com/en-us/library/system.configuration.applicationsettingsgroup.aspx.

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

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

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

1. Добавьте атрибут configSource=»user.config» в элемент <connectionStrings> главного конфигурационного файла приложения:

<configuration>

<connectionStrings configSource=”user.config”/> </configuration>

2. Чтобы переопределить главный конфигурационный файл приложения, создайте файл User.config (расположив его в той же папке, что и конфигурационный файл приложения) и затем добавьте такую же запись <connectionStrings>в этот файл.

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

<connectionStrings>

<add name=»DBConnStr» connectionString=»server=localhost;Integrated Security=SSPI;database=Accounts»/>

</connectionStrings> </configuration>

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

В этом коде используется статическое свойство ConnectionStrings класса System.Configuration.ConfigurationManager. В приложениях WinForm необходимо добавить явную ссылку на System.Configuration.dll.

using System.Configuration;

private string GetDBaseConnectionString()

{

return ConfigurationManager.ConnectionStrings[«DBConnStr»].ConnectionString;

}

4. Убедитесь, что файл User.config разворачивается вместе с кодом приложения. Для этого в Solution Explorer щелкните правой кнопкой мыши файл User.config, выберите Properties и затем в окне Properties задайте свойству Copy To Output Directory значение Copy if newer.

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

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

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

флажок напротив файла User.config. После этого можно щелкнуть правой кнопкой мыши файл в Solution Explorer и выбрать опцию Undo Pending Changes. Тогда файл гарантированно не будет подлежать контролю версий.

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

Дополнительные источники

Об использовании конфигурационного файла для определения источника данных подробно рассказывается в статье «Walkthrough: Using a Configuration File to Define a Data Source» (По шагам: использование конфигурационного файла для определения источника данных) по адресу http://msdn2.microsoft.com/en-us/library/ms243192(VS.80).aspx.

Больше информации об атрибуте configSource можно найти в статье «Sectionlnformation.ConfigSource Property» (Свойство Sectionlnformation.ConfigSource) по адресу http://msdn2.microsoft.com/en-us/librarv/system.configuration.sectioninformation.configsource.aspx.

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

• Как организовывать доступ к TFS по Интернет

• Как оптимизировать производительность прокси-сервера TFS Version Control

Как организовывать доступ к TFS по Интернет

Существует три возможных способа доступа к TFS по Интернет:

• Использование соединения VPN. Можно предоставить доступ к TFS через виртуальную частную сеть (virtual private network, VPN).

• Публикация TFS через обратный прокси-сервер. Можно предоставить доступ к TFS через обратный прокси-сервер, такой как Microsoft Internet Security and Acceleration (ISA) Server.

• Размещение TFS во внешней сети (сценарии установки на внешнем по отношению к организации сервере). Можно разместить сервер TFS во внешней сети.

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

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

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

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

Если поддерживается одиночный клиент, устанавливающий соединение с удаленным TFS, конфигурируйте клиента для установления прямого соединения с TFS.

Дополнительные источники

Сценариям удаленного доступа к TFS посвящена Глава 17 «Обеспечение доступа к Team Foundation Server через Интернет» данного руководства.

Подробнее о Team Foundation Server Proxy рассказывает статья «Team Foundation Server Proxy and Source Control» по адресу http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx.

О проверке производительности прокси-сервера TFS подробнее рассказывает статья «How to: Examine Cache Performance for Team Foundation Server Proxy» (Как: проверить производительность кэша для Team Foundation Server Proxy) по адресу http://msdn2.microsoft.com/en-us/library/ms252455(VS.80).aspx.

Как оптимизировать производительность прокси-сервера TFS Version Control

В удаленном офисе установите и конфигурируйте Team Foundation Server Proxy. Это обеспечит повышение производительности за счет кэширования файлов системы контроля версий на удаленном прокси-сервере.

Чтобы конфигурировать и оптимизировать производительность прокси-сервера:

1. Убедитесь, что кэширование активировано, и отслеживайте производительность кэша. Регулярно проверяйте счетчики производительности (устанавливаемые по умолчанию) и протоколы событий (для ошибок/предупреждений) на своем прокси-сервере.

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

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

3. Если известно, что предполагается загрузка больших файлов через канал с малой полосой пропускания (< 3 мегабита в секунду [Mbps]), задайте соответствующее значение атрибуту executionTimeout в файле Web.config. По умолчанию это значение — один час, <httpRuntime executionTimeout=»3600″/>.

Дополнительные источники

Сценариям удаленного доступа к TFS посвящена Глава 17 «Обеспечение доступа к Team Foundation Server через Интернет» данного руководства.

Подробнее о Team Foundation Server Proxy рассказывает статья «Team Foundation Server Proxy and Source Control» по адресу http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx.

Более подробную информацию о проверке производительности прокси-сервера TFS можно найти по адресу http://msdn2.microsoft.com/en-us/library/ms252455(VS.80).aspx.

Больше информации о TFS Proxy File Cache Server представлено в MSDN Webcast по адресу

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventlD=1032291120&CountryCode=US.

Миграция

• Как перенести исходный код из Visual SourceSafe

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

Как перенести исходный код из Visual SourceSafe

Чтобы перенести исходный код из VSS, выполните следующее.

Примечание: Чтобы осуществлять эти действия, вы должны быть членом группы Team Foundation Administrators.

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

2. Проанализируйте свои проекты. Используйте инструмент командной строки конвертер (VSSConverter.exe), передавая управляющий ключ analyze вместе с именем XML-файла настроек:

VSSConverter analyze conversionsettings.xml

Вот пример XMLфайла настроек:

<?xml version=»1.0″ encoding=»utf-8″?> <SourceControlConverter>

<ConverterSpecificSetting> <Source name=»VSS»>

<VSSDatabase name=»c:\VSSDatabase»></VSSDatabase> </Source> <ProjectMap>

<Project Source=»$/MyFirstProject»></Project> <Project Source=»$/MySecondProject»></Project> </ProjectMap> </ConverterSpecificSetting> </SourceControlConverter>

Файл настроек содержит имя базы данных в VSS. Задаваемый вами атрибут name указывает на папку, содержащую .ini-файл вашей базы в SourceSafe. Элементы Project определяют пути к проектам в базе данных VSS, которые требуется перенести в TFS. Чтобы перенести всю базу данных VSS, используйте <Project Source=»$/»></Project>.

По команде analyze VssConverter.exe также формируется файл usermap.xml. добавляя отображения в этот файл, можно менять ассоциированную с версией историю и другие данные, начиная от регистрационных имен VSS, и заканчивая регистрационными именами TFS.

3. Перенесите свои проекты. Выберите папки, которые хотите перенести, и используйте VSSConverter.exe с аргументом migrate:

VSSConverter migrate conversionsettings.xml

Опять передается конфигурационный XML-файл настроек, но с двумя важными дополнениями:

<?xml version=»1.0″ encoding=»utf-8″?> <SourceControlConverter>

<ConverterSpecificSetting> <Source name=»VSS»>

<VSSDatabase name=»c:\VSSDatabase»></VSSDatabase> </Source> <ProjectMap>

<Project Source=»$/MyFirstProject» Destination=»$/MyTeam_ProjectOne»></Project>

<Project Source=»$/MySecondProject» Destination=»$/MyTeam_ProjectTwo»></Project> </ProjectMap> </ConverterSpecificSetting> <Settings>

<TeamFoundationServer name=»YourTFSServerName» port=»PortNumber» protocol=»http»></TeamFoundationServer> </Settings> </SourceControlConverter>

Обратите внимание на атрибут Destination (Место назначения) в элементах <Project>. Он указывает на ваш групповой проект в TFS (который должен быть создан заранее). Также обратите внимание на элемент <Settings>, содержащий данные соединения для уровня приложений вашего TFS.

Дополнительные источники

Подробно о подготовке к миграции рассказывается в статье «Walkthrough: Preparing to Migrate from Visual SourceSafe to Team Foundation» (По шагам: подготовка к миграции из Visual SourceSafe в Team Foundation) по адресу http://msdn2.microsoft.com/en-us/library/ms181246(en-us,vs.80).aspx.

Процесс миграции подробно описывается в статье «Walkthrough: Migrating from Visual SourceSafe to Team Foundation» (По шагам: миграция из Visual SourceSafe в Team Foundation) по адресу http://msdn2.microsoft.com/en-us/library/ms181247(VS.80).aspx.

Об ограничениях конвертера Visual SourceSafe рассказывает статья «Visual SourceSafe Converter Limitations» (Ограничения конвертера Visual SourceSafe) по адресу http://msdn2.microsoft.com/en-us/library/ms252491(VS.80).aspx.

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

Можно вручную экспортировать файлы из исходной системы контроля версий и затем импортировать их в Team Foundation Server Version Control. Если требуется сохранить историю файла или другие атрибуты из предыдущей системы контроля версий, вы можете написать собственный инструмент миграции, используя объектную модель Team Foundation Server Version Control.

В настоящее время компания Microsoft работает над конвертером ClearCase. О его готовности будет объявлено в блоге TFS Migration по адресу http://blogs.msdn.com/tfs_migration.

Компанией ComponentSoftware создан конвертер, совместимый с GNU RCS, CS-RCS, GNU CVS, Subversion (SVN) и Visual SourceSafe (VSS).

Дополнительные источники

Скачать Visual Studio Team Foundation Server SDK можно по адресу http://go.microsoft.com/fwlink/?linkid=68586.

Подробнее о расширяемости Team Foundation Version Control рассказывает статья «Walkthrough: The Version Control Object Model» по адресу http://msdn2.microsoft.com/en-us/library/bbl87335(VS.80).aspx.

Больше информации о конвертере ComponentSoftware можно найти на Вебсайте ComponentSoftware (http://www.componentsoftware.com/Products/Converter/).

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

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

• Как организовывать дерево исходного кода

• Как определять отображения рабочих пространств

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

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

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

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

Самые важные моменты при принятии решения:

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

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

К типовым структурам проектов относятся:

• Один проект на приложение. Один проект используется для хранения всех версий приложения. Для каждой выпускаемой версии в рамках проекта создается отдельная ветвь.

о Основания использовать эту структуру: упрощает перенос кода,

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

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

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

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

¦ Накопление ‘багажа’ от версии к версии. Проще всего избавиться от него, создав новый проект и в нем ветвь кода из предыдущего проекта.

• Один проект на версию. Для каждой версии приложения создается новый проект.

о Основания использовать эту структуру:

¦ Она отлично подходит, если требуется начинать каждую новую версию с чистого проекта.

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

¦ Перенос исходного кода из одного проекта в другой не составляет никакого труда.

о Основания не использовать эту структуру:

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

¦ При обслуживании сотен проектов может быть достигнут предел масштабируемости TFS.

При выборе стратегии следует учитывать следующее:

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

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

о Создания ветвей исходного кода одного проекта в другом. о Отображения исходного кода из другого проекта в ваше рабочее пространство.

Team Foundation Server может обслуживать до ~500 проектов при использовании шаблона процесса MSF Agile или 250 проектов при использовании MSF CMMI. При создании собственного шаблона процесса или настройке существующего следует помнить, что огромное влияние на

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

Дополнительные источники

Стратегия создания проектов посвящена запись блога Эрика Ли (Eric Lee) «When to use Team Projects» по адресу

http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx.

Как организовывать дерево исходного кода

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

• Main — Контейнер для всех ресурсов, необходимых для поставки продукта

о Source — Контейнер для всех ресурсов, необходимых для сборки

¦ Code — Контейнер исходного кода

¦ Shared Code — Контейнер исходного кода, позаимствованного для совместного использования из других проектов

¦ Unit Tests — Контейнер модульных тестов

¦ Lib — Контейнер используемых двоичных файлов

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

установки приложения о Tests — Контейнер сценариев тестирования группы тестирования

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

• Development — Ветвь разработки

о Source — Контейнер для всех ресурсов, необходимых для сборки

¦ Code — Контейнер исходного кода

¦ Shared Code — Контейнер исходного кода, позаимствованного для совместного использования из других проектов

¦ Unit Tests — Контейнер модульных тестов

¦ Lib — Контейнер используемых двоичных файлов

• Main — Ветвь интеграции

о Source — Контейнер для всех ресурсов, необходимых для сборки

¦ Code — Контейнер исходного кода

¦ Shared Code — Контейнер исходного кода, позаимствованного для совместного использования из других проектов

¦ Unit Tests — Контейнер модульных тестов

¦ Lib — Контейнер используемых двоичных файлов

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

установки приложения о Tests — Контейнер сценариев тестирования группы тестирования

Дополнительные источники

Подробнее о создании рабочего пространства рассказывается в статье «How to: Create a Workspace» по адресу http://msdn2.microsoft.com/en-us/library/msl81384(VS.80).aspx.

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

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

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

1. В Source Control Explorer выберите корневую папку каталога исходного кода.

2. Щелкните правой кнопкой мыши и выберите Get Latest Version.

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

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

1. Выберите File->Source Control->Workspaces.

2. С помощью диалогового окна Manage Workspaces можно добавлять, удалять или редактировать существующие рабочие пространства.

Для просмотра существующего отображения рабочего пространства

1. В Source Control Explorer выберите папку исходного кода.

2. Щелкните правой кнопкой мыши и щелкните Properties.

3. Отображение рабочего пространства на вашем локальном диске появится в поле Local Name (Локальное имя).

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

• Создание отображений на корневом уровне группового проекта. При

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

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

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

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

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

Дополнительные источники

Подробнее о создании рабочего пространства рассказывается в статье «How to: Create a Workspace» по адресу http://msdn2.microsoft.com/en-us/library/msl81384(VS.80).aspx.

Больше информации о редактировании рабочего пространства можно найти в статье «How to: Edit a Workspace» по адресу http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx.

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

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

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

1. В Source Control Explorer, щелкните выпадающий список Workspace и щелкните Workspaces.

2. В диалоговом окне Manage Workspaces щелкните Add.

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

4. В списке Working folders задайте статус рабочего пространства Active, укажите, что папка системы контроля версий должна быть включена в рабочее пространство (это может быть корневая папка группового проекта или любая подпапка), и определите путь к локальной папке на вашем компьютере, в которой будут располагаться файлы рабочего пространства.

5. Щелкните OK и Close для создания изолированного рабочего пространства.

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

1. В Source Control Explorer убедитесь, что имя вашего изолированного рабочего пространства выбрано в выпадающем списке Workspace.

2. Выберите корневую папку группового проекта (или подпапку, если нужна только часть дерева исходного кода), щелкните ее правой кнопкой мыши и выберите Get Latest Version.

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

Дополнительные источники

Подробнее о создании рабочего пространства рассказывается в статье «How to: Create a Workspace» по адресу http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx.

Больше информации о редактировании рабочего пространства можно найти в статье «How to: Edit a Workspace» по адресу http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx.

Безопасность

• Как защитить канал между рабочей станцией разработчика и TFS

Как защитить канал между рабочей станцией разработчика и TFS

Чтобы защитить канал между рабочей станцией разработчика и TFS, можно конфигурировать TFS на использование HTTPS и шифрования Secure Sockets Layer (SSL). Можно конфигурировать TFS на использование только HTTPS и SSL, запретив при этом HTTP-соединения. Для этого необходимо сначала разрешить HTTPS и SSL, а затем выполнить дополнительные шаги, чтобы HTTPS и SSL стали обязательными протоколами соединений.

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

Дополнительные источники

Больше информации представлено в статье «Securing Team Foundation Server with HTTPS and Secure Sockets Layer (SSL)» (Защита Team Foundation Server с помощью HTTPS и Secure Sockets Layer (SSL)) по адресу http://msdn2.microsoft.com/en-us/library/aa395265(VS.80).aspx.

О том, как настраивать TFS с Secure Socket Layer (SSL), подробно рассказывается в статье «Walkthrough: Setting up Team Foundation Server with Secure Sockets Layer (SSL)» (http://msdn2.microsoft.com/en-us/library/ms242875(VS.80).aspx).

Как конфигурировать TFS на использование только HTTPS и SSL, рассказывает статья «How to: Configure Team Foundation Server for HTTPS and SSL Only» (Как: конфигурировать Team Foundation Server на использование только HTTPS и SSL) по адресу http://msdn2.microsoft.com/en-us/library/aa395285(VS.80).aspx.

Возможность временно отложить изменения

• Как использовать возможность временно откладывать изменения для резервного копирования ожидающих регистрации изменений

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

Как использовать возможность временно откладывать изменения для резервного копирования ожидающих регистрации изменений

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

Чтобы отложить пакет ожидающих регистрации изменений

1. Просмотрите ожидающие регистрации изменения, щелкнув правой кнопкой мыши свое решение в Solution Explorer и выбрав View Pending Changes.

2. Выберите файлы, которые хотите отложить, и щелкните Shelve.

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

Чтобы восстановить свою работу на следующий день

1. В меню File выберите Source Control и щелкните Unshelve.

2. Выберите необходимый пакет отложенных изменений и щелкните Unshelve.

3. Team Foundation Server восстанавливает каждое временно отложенное изменение в заданное рабочее пространство как ожидающее регистрации изменение, если только это изменение не конфликтует с уже существующим в этом рабочем пространстве ожидающим регистрации изменением.

Дополнительные источники

Подробнее о том, как откладывать ожидающие регистрации изменения, рассказывается в статье «How to: Shelve and Unshelve Pending Changes» по адресу http://msdn2.microsoft.com/en-us/librarv/msl81404(VS.80).aspx.

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

Если вы хотите отложить исходный код, чтобы передать его другому участнику группы, синхронизируйте свое рабочее пространство с сервером с помощью операции Get Latest и затем выполните сборку своего приложения, чтобы убедиться, что оно компилируется. Отложите измененный исходный код, используя Source Control Explorer. Член группы, которому вы передаете код должен будет изъять этот временно отложенный код.

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

Чтобы временно отложить папки и файлы из Source Control Explorer

1. Щелкните правой кнопкой мыши в Source Control Explorer и выберите Shelve Pending Changes.

2. В диалоговом окне Shelve — Source Files (Отложить – исходные файлы) в поле Shelveset name (Имя пакета отложенных изменений) введите имя пакета отложенных изменений; например, shelvetest.

3. В поле Comment введите Testing my shelveset (Тестирование моего пакета отложенных изменений) и щелкните Shelve.

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

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

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

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

1. В Visual Studio 2005 Team System щелкните File, выберите Source Control и щелкните Unshelve.

2. В поле Owner name введите имя создателя пакета отложенных изменений (например, ADVENTUREWORKS\JuanGo или просто juango) и щелкните Find.

3. В окне Results выберите пакет временно отложенных изменений, который хотите восстановить в свое рабочее пространство, и щелкните Details.

4. Если хотите удалить пакет временно отложенных изменений с сервера системы контроля версий TFS, отмените выбор опции Preserve shelveset on server.

5. (Не обязательно) Отмените выбор опции Restore work items and check-in notes, если не хотите, чтобы с пакетом временно отложенных изменений восстанавливались ассоциированные с ним рабочие элементы и комментарии

к регистрациям изменений.

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

Дополнительные источники

Более подробную информацию можно найти в статье «How to: Shelve and Unshelve Pending Changes» по адресу http://msdn2.microsoft.com/en-us/librarv/msl81404(VS.80).aspx.

Дополнительные источники по системе контроля версий

Более подробная информация по Team Foundation Server Source Control представлена в статье «Team Foundation Source Control», которую можно найти по адресу http://msdn2.microsoft.com/en-us/library/msl81237(VS.80).aspx.

<< Назад

 
%d такие блоггеры, как: