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

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

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

<< Назад

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

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

Содержание

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

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

Использование Microsoft® Visual Studio® 2005 Team Foundation Power Tools (TFPT) для возвращения к работе над отложенным изменением.

Использование Team Foundation Power Tools для отката изменений.

Использование Team Foundation Power Tools для автономной работы.

Использование Team Foundation Power Tools для получения пакета изменений.

Использование Team Foundation Power Tools для удаления ожидающих регистрации изменений.

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

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

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

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

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

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

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

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

Не следует создавать слишком глубоко разветвленную структуру.

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

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

Полное слияние предпочтительнее, чем «избирательное».

Слияния должны выполняться часто.

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

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

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

Разрешать конфликты при слиянии следует с особой тщательностью и осторожностью.

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

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

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

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

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

При регистрации изменений в статус “завершен” переходит только один рабочий элемент.

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

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

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

Планирование во избежание конфликтов.

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

Получение последней версии исходного кода перед внесением изменений.

Разумное использование команды lock.

Обмен информацией с участниками группы при блокировке файлов.

Зависимости

Максимально широкое использование ссылок на проекты.

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

Использование copy local = true для ссылок на проекты и файлы.

Использование динамических URL в ссылках на Веб-сервисы.

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

На прокси-сервере должен быть диск соответствующего объема.

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

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

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

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

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

Миграция

Использование конвертера VSS для миграции в Team Foundation Server Source Control.

Миграция в Team Foundation Server Source Control из других систем контроля версий.

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

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

Удаление и переименование файлов выполняется в системе контроля версий, а не в Microsoft Windows® Explorer.

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

Создание одного группового проекта на приложение, если предполагается перенос ресурсов TFS из версии в версию.

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование Microsoft® Visual Studio® 2005 Team Foundation Power Tools (TFPT)

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

регистрации изменений.

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

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

Чтобы убедиться в правильности задания пути и других переменных окружения, запустите Tf.exe из окна Visual Studio 2005 Command Prompt или командный файл Vsvars32, который обычно размещается в каталоге DriveLetter:\Program Files\Microsoft Visual Studio 8\Common7\Tools. Инструмент Tf.exe поддерживает большинство команд системы контроля версий, включая Checkin (Регистрировать изменения), Checkout (Изъять для редактирования), Get (Получить), History (История), Shelve (Временно отложить изменения), Branch (Ветвление), Merge

(Слияние), Label (Метка), Status (Статус), Undelete (Восстановить) и Undo (Отменить).

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

Синхронизация файлов с сервера на локальный компьютер – tf get

Добавление файла на сервер – tf add

Изъятие файла для редактирования – tf checkout

Регистрация ожидающих регистрации изменений – tf checkin

Извлечение с сервера конкретного пакета изменений – tf get /version

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

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

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

Отмена блокировки, установленной другим пользователем – tf lock

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

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

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

Для получения более подробной информации обратитесь к статье «Walkthrough: Working with Team Foundation Source Control from Command Line» (По шагам: работа с Team Foundation Source Control из командной строки), размещенной на Веб-сайте Microsoft MSDN® по адресу http://msdn2.microsoft.com/en-us/library/zthc5x3f.aspx .

Подробнее о командах, доступных только из командной строки, рассказывает статья «Operations Available Only From the Command-Line (Team Foundation Source Control)» (Операции, доступные только из командной строки (Team Foundation Source Control)) по адресу http://msdn2.microsoft.com/en-us/library/ms194957(VS.80).aspx.

Использование Team Foundation Power Tools (TFPT) для возвращения к работе над отложенным изменением

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

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

коррективой, и отложенное изменение – тоже корректива, TFPT может объединить изменения тройным слиянием.

Эта команда выполняется из командной строки с помощью Tfpt.exe.

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

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

Форум, на котором обсуждается Team Foundation Power Tools, находится по адресу http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1.

Использование Team Foundation Power Tools для отката изменений

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

Эта команда выполняется из командной строки с помощью Tfpt.exe.

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

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

Форум, на котором обсуждается Team Foundation Power Tools, находится по адресу http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1.

Использование Team Foundation Power Tools для автономной работы

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

1. Вручную снять флаги read-only (только для чтения).

2. Отредактировать файлы.

3. Добавить или удалить файлы.

4. Выполнить команду TFPT online.

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

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

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.

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

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

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

Форум, на котором обсуждается Team Foundation Power Tools, находится по адресу http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1.

Использование Team Foundation Power Tools для получения пакета изменений

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

Эта команда выполняется из командной строки с помощью Tfpt.exe.

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

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

Форум, на котором обсуждается Team Foundation Power Tools, находится по адресу http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1.

Использование Team Foundation Power Tools для удаления ожидающих регистрации изменений

TFPT можно использовать для снятия с файлов пометки «ожидается регистрация корректив». Команда TFPT Undo Unchanged (отменить фактически отсутствующие изменения) исключает из списка ожидающих регистрации изменений файлы, которые фактически не редактировались. Это полезно, когда для редактирования изымается большое количество файлов, но в конечном счете изменения вносятся только в некоторые из них. Можно исключить из списка ожидающих регистрации изменений фактически неизмененные файлы, применяя инструмент TFPT UU, который определяет, был ли файл действительно изменен, сравнивая хэш файла в локальном рабочем пространстве с хэшем файла на сервере.

Эта команда выполняется из командной строки с помощью Tfpt.exe.

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

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

Форум, на котором обсуждается Team Foundation Power Tools, находится по адресу http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1.

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

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

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

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

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

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

Подробнее об отмене прав доступа рассказывается в статье «How to: Remove Access to Source Control Files» (Как: отменить доступ к файлам системы контроля версий) по адресу http://msdn2.microsoft.com/en-us/library/ms400718(VS.80).aspx.

Отказ в праве регистрировать изменения разработчикам, которым вы еще не доверяете вносить изменения в исходный код

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

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

Подробнее об отмене прав доступа рассказывается в статье «How to: Remove Access to Source Control Files» по адресу http://msdn2.microsoft.com/en-us/library/ms400718(VS.80).aspx.

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

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

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

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

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

Не следует создавать слишком глубоко разветвленную структуру.

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

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

Полное слияние предпочтительнее, чем «избирательное». Слияния должны выполняться часто.

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

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

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

Разрешать конфликты при слиянии следует с особой тщательностью иосторожностью.

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

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

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

Маркируя метками ежедневные сборки, мы обеспечиваем возможность без труда просматривать и извлекать набор файлов, используемый для конкретной сборки. Team Build автоматически присваивает метку набору файлов, ассоциированному с каждой создаваемой им сборкой. Для меток Team Build используется формат «ТипВерсии_Сборка#»; например, «Releasex86_20070226.1».

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

Внутренняя контрольная точка; например, альфа-версия

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

Чтобы позже можно было понять, что представляет собой сборка, следует придерживаться какого-то соглашения об именах меток. Имена должны быть информативными и описательными. Скажем, можно использовать такой формат имени «ИмяМетки_Дата» (например, «AlphaBuild_20070112»).

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

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

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

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

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

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

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

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

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

  • Main – Ветвь интеграции
    • Source
    • Other Asset Folders
  • Releases – Контейнер ветвей обслуживания
    • Release 1 – Ветвь обслуживания
      • Source

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

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

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

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

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

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

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

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

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

Например:

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

  • Development – Ветвь разработки
  • Main – Ветвь интеграции
  • Releases – Контейнер ветвей выпущенных версий
    • Release 1 – Ветвь выпущенной версии

Логическая структура:

  • Main
    • Development
    • Release 1

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

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

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

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

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

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

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

  • Main – контейнер для всех ресурсов, которые необходимы для поставки продукта
    • Source – контейнер для всех ресурсов, необходимых для сборки
      • Code – контейнер исходного кода
      • Shared Code – контейнер исходного кода, позаимствованного для совместного использования из других проектов
      • Unit Tests – контейнер модульных тестов
      • Lib – контейнер используемых двоичных файлов
    • Docs – контейнер для документации, которая будет поставляться с продуктом
    • Installer – контейнер исходного кода и двоичных файлов пакета установки приложения
    • Tests – контейнер сценариев тестирования группы тестирования

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

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

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

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

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

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

Не следует создавать слишком глубоко разветвленную структуру

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

  • Development – Контейнер ветвей разработки
    • Development Branch
      • Sub-Branch
        • Sub-Sub-Branch
  • Main – Ветвь интеграции
    • Source
    • Other Asset Folders

слияния вдоль иерархии ветвления приводят к меньшему количеству конфликтов. Поэтому, чтобы перенести изменение из ветви Sub-Sub-Branch (под-подветвь) в ветвь Main, пришлось бы сначала выполнить слияние с Sub-Branch (подветвь) и Development Branch, а затем уже с 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/ms181425(VS.80).aspx.

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

Дополнительное описание процессов ветвления и слияния в Visual Studio 2005

можно найти в статье «Branching and Merging Team Foundation Source Control» по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Development — Ветвь разработки
  • Main – Ветвь интеграции
  • Releases – Контейнер ветвей выпущенных версий
    • Release 1 – Ветвь выпущенной версии

Логическая структура:

  • Main
    • Development
    • Release 1

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

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

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

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

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

Полное слияние предпочтительнее, чем «избирательное»

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

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

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

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

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

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

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

Слияния должны выполняться часто

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

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

  • Development – Папка для изолированных ветвей разработки
    • External — Ветвь внешних зависимостей
    • Team 1 — Ветвь группы
    • Team 2 — Ветвь группы
      • Feature A – Ветвь функциональной возможности
      • Feature B – Ветвь функциональной возможности
      • Feature C – Ветвь функциональной возможности
  • Main – Ветвь интеграции
  • Releases — Папка для ветвей выпущенных версий
    • Release 2 – Ветвь выпущенной версии
  • Safe Keeping — Папка для ветвей архивного хранения
    • Release 1 — Ветвь архивного хранения

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

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

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

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

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

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

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

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

  • Development – Папка для изолированных ветвей разработки, ответвленная от Main
    • Feature A
      • Source
    • Feature B
      • Source
  • Main – Ветвь интеграции
    • Source
    • Other Asset Folders
  • Releases – Папка для ветвей выпущенных версий, ответвленная от Main
    • Release 1 – Ветвь обслуживания
      • Source

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

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

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

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

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

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

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

Предварительный просмотр результатов слияния можно получить с помощью инструмента командной строки Tf.exe и команды merge с ключами preview или candidate. Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разрешать конфликты при слиянии следует с особой тщательностью и осторожностью

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

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

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

Более подробно о разрешении конфликтов слияния рассказывает статья «Resolving Conflicts» (Разрешение конфликтов), которую можно найти на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/ms181432(VS.80).aspx.

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее о ветвлении рассказывает статья «How to: Branch Files and Folders» at http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx.

Подробнее о слиянии рассказывает статья «How to: Merge Files and Folders» at http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx.

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

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

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

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

При регистрации изменений в статус «завершен» переходит только один рабочий элемент.

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

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

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

Планирование во избежание конфликтов.

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

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

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

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

Подробнее о регистрации изменений рассказывается в статье «How to: Check In Pending Changes», которую можно найти по адресу http://msdn2.microsoft.com/en-us/library/ms181411(VS.80).aspx.

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

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

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

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

  • В меню File выберите Source Control и щелкните Unshelve.
  • В текстовое поле Owner name (Имя владельца) введите имя создателя пакета временно отложенных изменений (например, Contoso\JimB ил просто JimB) и щелкните Find (Найти).
  • В окне Results (Результаты) выберите пакет временно отложенных изменений, который хотите вернуть в свое рабочее пространство и щелкните Details (Детали).

Если хотите удалить пакет временно отложенных изменений после его извлечения с сервера системы контроля версий TFS, отмените выбор опции Preserve shelveset on server (Сохранять пакет временно отложенных изменений на сервере). Team Foundation Server восстанавливает все отложенные версии в заданном рабочем пространстве как ожидающие регистрации изменения, если эти версии не конфликтуют с ожидающими регистрации изменениями, уже присутствующими в вашем рабочем пространстве.

По желанию, можно отменить выбор опции Restore work items and check-in notes (Восстановить рабочие элементы и комментарии к регистрации изменений), если вы не хотите, чтобы с пакетом временно отложенных изменений восстанавливались ассоциированные с ним рабочие элементы и комментарии к регистрациям изменений. В диалоговом окне Details выберите пакет временно отложенных изменений или элементы пакета временно отложенных изменений, которые хотите вернуть в свое рабочее пространство, и щелкните Unshelve.

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

Более подробную информацию можно найти в статье «How to: Shelve and Unshelve Pending Changes» (Как: откладывать работу над изменениями и возвращаться к ним) по адресу http://msdn2.microsoft.com/en-us/library/ms181404(VS.80).aspx.

При регистрации изменений в статус «завершен» переходит только один рабочий элемент

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

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

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

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

Подробнее о регистрации изменений рассказывается в статье «How to: Check In Pending Changes», которую можно найти по адресу http://msdn2.microsoft.com/en-us/library/ms181411(VS.80).aspx.

Больше информации о рабочих элементах и пакетах изменений можно найти в статье «How to: Associate Work Items with Changesets» по адресу http://msdn2.microsoft.com/en-us/library/ms181410(VS.80).aspx.

Более подробно о том, как просматривать данные рабочих элементов, рассказывает статья «How to: View Work Item Details from Pending Changes Window» (Как: просматривать данные рабочих элементов из окна «Ожидающие регистрации изменения») по адресу http://msdn2.microsoft.com/en-us/library/ms245467(VS.80).aspx.

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

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

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

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

  • В Team Explorer щелкните правой кнопкой мыши групповой проект, выберите Team Project Settings и щелкните Source Control.
  • Выберите вкладку Check-in Policy и щелкните Add.
  • В диалоговом окне Add Check-in Policy выберите Code Analysis и щелкните OK.
  • В редакторе Code Analysis Policy Editor выберите или Enforce C/C++ Code Analysis (/analyze), или Enforce Code Analysis For Managed Code. Выберите обе опции, если в проекте используется как управляемый, так и неуправляемый код.
  • Если выбрана опция Enforce Code Analysis For Managed Code, конфигурируйте необходимые настройки правил для анализа управляемого кода на основании требуемых стандартов написания кода, тем самым точно определяя, какие правила будут действовать.

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

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

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

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

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

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

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

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

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

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

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

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

Выберите вкладку Check-in Policy, щелкните Add и затем выберите и конфигурируйте соответствующую политику.

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

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

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

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

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

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

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

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

С помощью Team Foundation Server Eventing Service (из Team Foundation Core Services API) перехватываем события регистрации изменений.

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

Или можно самостоятельно просматривать историю изменений.

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

Больше узнать о переопределении политики регистрации изменений можно в статье «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/bb130154(vs.80).aspx.

О том, как настроить уведомление о нарушении политики по электронной почте, рассказывается в блоге http://blogs.infosupport.com/marcelv/archive/2005/10/18/1635.aspx.

Планирование во избежание конфликтов

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

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

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

1. В окне Team Explorer в Visual Studio щелкните двойным щелчком Source Control.

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

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

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

Tf status /format:detailed /user:*

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

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

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

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

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

Получение последней версии исходного кода перед внесением изменений.

Разумное использование команды lock.

Обмен информацией с участниками группы при блокировке файлов.

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

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

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

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

Больше информации о команде Get можно найти в статье «Get Command» (Команда Get), размещенной на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/fx7sdeyf(VS.80).aspx.

Разумное использование команды lock

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

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

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

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

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

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

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

1. В Source Control Explorer щелкните файл правой кнопкой мыши и затем щелкните Check Out for Edit (Изъять для редактирования).

2. Задайте тип блокировки: None (нет), Check Out (блокировка изъятия для редактирования) или Check In (блокировка регистрации изменений).

3. Чтобы явно заблокировать файл, щелкните по нему правой кнопкой мыши, выберите в меню Lock и затем выберите тип блокировки Check Out или Check In.

Обратите внимание, что в отличие от Microsoft Visual Source Safe® (VSS), при изъятии файла для редактирования не гарантируется, что будет получена последняя версия. Перед блокировкой файла убедитесь, что в вашем рабочем

пространстве находится именно последняя версия файла, щелкнув Get Latest Version.

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

Подробнее о блокировках рассказывает статья «How to: Lock and Unlock Folders or Files» (Как: блокировать и разблокировать папки и файлы), которую можно найти по адресу http://msdn2.microsoft.com/en-us/library/ms181420(VS.80).aspx.

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

Обмен информацией с участниками группы при блокировке файлов

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

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

Чтобы блокировать файл из Source Control Explorer, щелкните его правой кнопкой мыши, щелкните Lock и затем выберите тип блокировки Check Out или Check In.

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

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

Зависимости

Максимально широкое использование ссылок на проекты.

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

Использование copy local = true для ссылок на проекты и файлы.

Использование динамических URL в ссылках на Веб-сервисы.

Максимально широкое использование ссылок на проекты

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

  • Ссылки на проекты работают на всех рабочих станциях разработки, на которых загружен набор решений и проектов, поскольку в файле проекта размещается Globally Unique Identifier (GUID)1, уникально идентифицирующий используемый проект в контексте текущего решения.
  • При использовании ссылок на проекты система сборки Visual Studio имеет возможность отслеживать зависимости проекта и правильно определять порядок сборки проекта.
  • Ссылки на проекты исключают возможность утери используемых сборок на отдельном компьютере.
  • Ссылки на проекты автоматически отслеживают изменения в конфигурации проекта. Например, при сборке с использованием конфигурации для отладки все ссылки на проекты ссылаются на сборки для отладки, сформированные проектами, на которые указывают эти ссылки, тогда как в конфигурации для выпуска они указывают на сборки для выпуска. Это означает, что можно автоматически переходить от сборок для отладки к сборкам для выпуска и при этом не приходится переопределять ссылки.
  • При использовании ссылок на проекты Visual Studio может выявлять и предотвращать циклические зависимости.

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

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

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

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

Подробнее о добавлении ссылок рассказывает статья «How to: Add or Remove References in Visual Studio» (Как: добавлять или удалять ссылки в Visual Studio), которую можно найти по адресу http://msdn2.microsoft.com/en-us/library/wkze6zky(VS.80).aspx.

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

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

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

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

1Глобально уникальный идентификатор (прим. переводчика)

Использование copy local = true для ссылок на проекты и файлы

Каждая ссылка имеет ассоциированный с ней атрибут copy local (копировать в папку результатов сборки).Visual Studio определяет исходное значение этого атрибута (true или false) при создании ссылки. Значение false присваивается, если данная сборка располагается в Global Assembly Cache (GAC)1; в противном случае, присваивается значение true.

Это значение по умолчанию менять не следует.

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

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

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

Использование динамических URL в ссылках на Веб-сервисы

Если требуется вызвать Веб-сервис, необходимо сначала добавить в проект Веб-ссылку. В результате этого будет сформирован прокси-класс, посредством которого будет осуществляться взаимодействие с Веб-сервисом. Код прокси-класса изначально содержит статический Uniform Resource Locator (URL) Веб-сервиса; например, http://localhost или http://НекоторыйВебСервер.

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

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

1Глобальный кэш сборок (прим. переводчика)

Можно программно задать URL Веб-сервиса при создании экземпляра прокси-класса.

Более гибкий подход, который позволяет избежать жесткого кодирования URL в прокси-классе, — задать свойству URL Behavior ссылки на Веб-сервис значение Dynamic. Если задано значение Dynamic, в прокси-класс добавляется код для извлечения URL Веб-сервиса из специальной секции конфигурационного файла приложения: Web.config для Веб-приложения или SomeApp.exe.config для приложения Windows.

Также можно сформировать прокси-класс, используя инструмент командной строки WSDLexe и ключ /urlkey. Это обеспечивает эффект, аналогичный заданию свойства URL Behavior, т.е. в прокси-класс добавляется код для извлечения URL Веб-сервиса, но в данном случае URL хранится в секции <applicationSettings> конфигурационного файла приложения.

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

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

Больше информации можно найти в Главе 6 «Управление зависимостями системы контроля версий в Visual Studio Team System» данного руководства.

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

На прокси-сервере должен быть диск соответствующего объема.

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

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

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

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

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

На прокси-сервере должен быть диск соответствующего объема

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

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

Более подробную информацию о Team Foundation Server Proxy можно найти в статье «Team Foundation Server Proxy and Source Control» (Team Foundation Server Proxy и система контроля версий) на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx.

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

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

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

Более подробную информацию о Team Foundation Server Proxy можно найти в

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

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

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

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

  • Текущий размер кэша
  • Общее число результативных обращений к кэшу – количество и процентное соотношение
  • Общее число запросов на скачивание
  • Общее число файлов в кэше
  • Общее число нерезультативных обращений к кэшу — количество и процентное соотношение

Эти счетчики производительности регистрируются при установке прокси-сервера. Счетчики производительности прокси-сервера могут иметь множество экземпляров, т.е. для каждого уровня приложений (т.е. для каждого известного прокси экземпляра TFS, для которого осуществляется кеширование – прим. науч. редактора), заданного в файле Proxy.config, существует свой набор счетчиков. Эти данные формируют картину производительности при работе прокси-сервера.

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

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

Более подробную информацию о Team Foundation Server Proxy можно найти в

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

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

Если известно, что предполагается загрузка больших файлов через канал с малой полосой пропускания (< 3 мегабит в секунду *Mbps+), задайте соответствующее значение атрибуту executionTimeout в файле Web.config. Это делается для сокращения вероятности возникновения ошибки из-за истечения времени ожидания. По умолчанию это значение равно одному часу, как показано здесь:

<httpRuntime executionTimeout=»3600″/>.

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

Более подробную информацию о Team Foundation Server Proxy можно найти в

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

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

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

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

Более подробную информацию о Team Foundation Server Proxy можно найти в

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

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

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

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

Чтобы сокрыть папки в рабочем пространстве

  • В Visual Studio в меню File выберите Source Control и затем щелкните Workspaces (Рабочие пространства).
  • В диалоговом окне Manage Workspaces (Управление рабочими пространствами) выберите рабочее пространство, к которому хотите применить сокрытие, и щелкните Edit.
  • В диалоговом окне Edit Workspace (Редактировать рабочее пространство) в списке Working folders (Рабочие папки) выберите отображение папки, расположенное под Source Control Folder (Папка системы контроля версий) и Local Folder (Локальная папка), которое желаете сокрыть, или создайте новое отображение папки.
  • Щелкните столбец Status и измените настройку Active (Активная) на Cloaked (Скрытая). Обратите внимание, что скрывать можно только папки в папке системы контроля версий TFS, отображение которой само по себе активно.
  • Щелкните OK, чтобы закрыть окно Edit Workspace, и щелкните Close, чтобы закрыть окно Manage Workspaces.

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

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

Более подробную информацию о Team Foundation Server Proxy можно найти в статье «Team Foundation Server Proxy and Source Control» на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx.

Миграция

Использование конвертера VSS для миграции в Team Foundation Server Source Control.

Миграция в Team Foundation Server Source Control из других систем контроля версий.

Использование конвертера VSS для миграции в Team Foundation Server Source Control

Team Foundation Server поставляется с конвертером VSS, с помощью которого можно переносить файлы, папки, историю версий, метки и информацию пользователя из базы данных Visual SourceSafe в Team Foundation Server Version Control.

Однако конвертер имеет некоторые ограничения, которые важно понимать, например:

  • История совместного использования файла не сохраняется. Team Foundation Server не поддерживает совместного использования. Миграция совместно используемых файлов заключается в копировании файла в заданную папку.
  • История ветвления не сохраняется.
  • Team Foundation Server не поддерживает фиксации версий. Файлы с зафиксированными версиями переносятся путем создания двух меток.
  • Временные метки, ассоциированные с действиями, при миграции не сохраняются.

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

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

Миграция в Team Foundation Server Source Control из других систем контроля версий

При выполнении переноса можно вручную экспортировать файлы из исходной системы контроля версий и импортировать их в Team Foundation Server Version Control. Если требуется сохранить историю изменений файла или другие атрибуты системы контроля версий, из которой производится миграция, можно написать собственный инструмент миграции, используя TFS Migration and Synchronization Toolkit (Комплект инструментов миграции и синхронизации) (http://www.codeplex.com/MigrationSyncToolkit).

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

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

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

Более подробную информацию о миграции TFS вы найдете в материале «TFS

Migration blog» на Веб-сайте MSDN Web по адресу

http://blogs.msdn.com/tfs_migration. Скачать TFS Migration and Synchronization Toolkit с CodePlex можно по адресу

http://www.codeplex.com/MigrationSyncToolkit. Более подробную информацию о конвертере Component Software можно найти по

адресу http://www.componentsoftware.com/Products/Converter/.

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

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

Удаление и переименование файлов выполняется в системе контроля версий, а не в Microsoft Windows® Explorer.

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

Создание одного группового проекта на приложение, если предполагается перенос ресурсов TFS из версии в версию.

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

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

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

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

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

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

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

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

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

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

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.

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

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

Чтобы уничтожить файл или папку, используя Source Control Explorer

1. В Source Control Explorer выберите файл или папку.

2. Щелкните правой кнопкой мыши выбранный файл или папку и щелкните Delete.

Слева появляется значок, показывающий, что элемент удален, и в столбце Pending Change (Ожидающее регистрации изменение) отображается статус «delete» (удалить). Этот элемент будет удален при следующей регистрации изменений в системе контроля версий.

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

Если необходимо выполнить операцию над несколькими файлами или папками, особенно пригодятся команды Tf move, delete и rename. Используя Source Control Explorer, можно перемещать, переименовывать или уничтожать файлы и папки только по одному.

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

Подробнее о команде Tf delete рассказывается в статье «Delete Command» (Команда Delete), которую можно найти на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/k45zb450(VS.80).aspx.

Подробнее о команде Tf rename рассказывается в статье «Rename Command» (Команда Rename), которую можно найти на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/a79bz90w(VS.80).aspx.

Удаление и переименование файлов и папок должно осуществляться только, когда решение открыто

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

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

Подробнее о команде Tf delete рассказывается в статье «Delete Command», которую можно найти на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/k45zb450(VS.80).aspx.

Подробнее о команде Tf rename рассказывается в статье «Rename Command», которую можно найти на Веб-сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/a79bz90w(VS.80).aspx.

Создание одного группового проекта на приложение, если предполагается перенос ресурсов TFS из версии в версию

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

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

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

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

Подробнее об использовании групповых проектов рассказывает статья «When to use Team Projects» (Когда использовать групповые проекты) по адресу http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx.

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

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

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

  • Тогда как перенос исходного кода из проекта в проект не представляет особой сложности, перенести рабочие элементы и другие ресурсы TFS трудно. Рабочие элементы можно копировать в другой проект только по одному, поэтому если требуется перенести множество рабочих элементов, придется создавать собственную сервисную программу.
  • TFS не сможет обслуживать сотни приложений и их версий, каждое из которых будет иметь собственный проект, он достигнет пределов производительности и масштабируемости.
  • Необходимо выбрать структуру, которая сможет использоваться в течение долгого промежутка времени, потому что реструктуризировать существующие групповые проекты сложно.
  • Групповые проекты могут без труда совместно использовать исходный код посредством:
    • Создания ветвей исходного кода одного проекта в другом.
    • Отображения исходного кода из другого проекта в ваше рабочее пространство.
  • Team Foundation Server может обслуживать до ~500 проектов при использовании шаблона процесса MSF Agile или 250 проектов при использовании MSF CMMI. При создании собственного процесса или настройке существующего следует помнить, что огромное влияние на масштабируемость сервера имеет схема рабочих элементов. Чем сложнее схема, тем меньше проектов сможет поддерживать сервер.

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

Подробнее об использовании групповых проектов рассказывает статья «When to use Team Projects» по адресу http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx.

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

Работа с совместно используемым кодом или двоичными файлами включает два этапа:

1. Определение места хранения зависимости.

2. Создание ветви зависимости в вашем проекте.

1. Определение места хранения зависимости.

Варианты хранения:

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

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

2. Создание ветви зависимости в вашем проекте.

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

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

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

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

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

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

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

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

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

Подробнее о создании рабочего пространства рассказывается в статье «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.

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

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

($/MyTeamProject) отображается в локальную папку с таким же именем; например, C: \MyTeamProject. Отображения рекурсивны, поэтому вся локальная структура каталогов создается автоматически и будет точно повторять структуру каталогов системы контроля версий.

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

Подробнее о создании рабочего пространства рассказывается в статье «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.

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

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

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

Подробнее о создании рабочего пространства рассказывается в статье «How to: Create a Workspace» по адресу http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx.

Больше информации о редактировании рабочего пространства можно найти в статье «How to: Edit a Workspace» по адресу http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx.

Отображение только части дерева исходного кода

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

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

Подробнее о создании рабочего пространства рассказывается в статье «How to: 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.

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

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

  • 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/ms181384(VS.80).aspx.

Больше информации о редактировании рабочего пространства можно найти в статье «How to: Edit a Workspace» по адресу http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx.

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

 

 

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

Если требуется обсудить или получить отзыв о разрабатываемом коде от члена группы, работающего удаленно, используйте возможность временно отложить изменение. Вместо того чтобы посылать код по электронной почте, можно отложить его регистрацию (буквально — «положить на полку», shelve – прим. перев.) и попросить своего удаленного коллегу «взять файлы с полки».

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

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

Более подробную информацию о том, как откладывать ожидающие регистрации изменений можно найти в статье «How to: Shelve and Unshelve Pending Changes» по адресу http://msdn2.microsoft.com/en-us/library/ms181404(VS.80).aspx.

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

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

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

Более подробную информацию о возможности временно отложить ожидающие регистрации изменения можно найти в статье «How to: Shelve and Unshelve Pending Changes» по адресу http://msdn2.microsoft.com/en-us/library/ms181404(VS.80).aspx.

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

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

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

Более подробную информацию о возможности временно отложить ожидающие регистрации изменения можно найти в статье «How to: Shelve and Unshelve Pending Changes» по адресу http://msdn2.microsoft.com/en-us/library/ms181404(VS.80).aspx.

Дополнительные источники по системе контроля версий

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

<< Назад

Реклама

комментария 2 to “Рекомендации: система контроля версий”

  1. […] (с) Шамрай Александр Владимирович […]

  2. […] (с) Шамрай Александр Владимирович […]

 
%d такие блоггеры, как: