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

Как прекратить поддержку старого выпуска

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

• Main - главная ветвь сборки.
  • Source.
  • Другие папки ресурсов.
• Releases - контейнер для ветвей выпусков.
  • Release 2 - ветвь сопровождения.
    • Source.
    • Другие папки ресурсов.
• Архив - контейнер для архивного хранения ветвей.
  • Release 1 - архивная ветвь.
    • Source.
    • Другие папки ресурсов.

Перемещая ветви из папки Releases в архив, вы разгружаете папку Releases и одновременно сохраняете старые выпуски. Это не создание новой ветви, а, скорее, перемещение старой ветви в новую папку.

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

• Вводный курс по ветвлению и слиянию вы найдете в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/ aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/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 или команду tf merge. Слияние выполняется по набору изменений, метке, дате или версии. Чтобы приступить к слиянию, щелкните правой кнопкой ветвь в Source Control и выберите команду Merge. Мастер Source Control Merge Wizard поможет выбрать целевую ветвь (в которую будет выполнено слияние).

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

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

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

• Development - ветвь разработки.
• Main - главная ветвь сборки.
• Releases - контейнер для ветвей выпусков.
  • Release 1 - ветвь выпуска.
    • Логическая структура.
• Main.
• Development.
  • Release 1.

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

• Дополнительную информацию о слиянии вы найдете в статье "Under standing Merging" по адресу http://msdn2.microsoft.com/en-us/library/ms181427(VS.80).aspx.
• О том, как выполнить слияние, читайте в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx.

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

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

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

merge /baseless <<путь_к_источнику>> <<конечный_путь>> /recursive

Например,

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

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

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

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

• Описание синтаксиса команды merge вы найдете в статье "Merge Command" по адресу http://msdn2.microsoft.com/en-us/library/bd6dxhfy(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "Understanding Merging" по адресу http://msdn2.microsoft.com/en-us/library/ms 181427(VS.80).aspx.
• О том, как выполнить слияние, читайте в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library/ms181428 (VS.80).aspx.

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

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

• Версии Файл эволюционировал по нескольким различным траекториям. Это может быть результатом редактирования, переименования, удаления и отмены удаления файла.
• Неоднозначность имени файла Два или несколько элементов пытаются занять одно расположение.
• Локальная перезапись Возникает только во время выполнения операции get при попытке перезаписать редактируемый файл. Большинство конфликтов может быть разрешено автоматически.

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

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

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

Разрешив все конфликты в файле, сохраните окончательную версию как незавершенное изменение в целевой ветви.

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

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

• Дополнительную информацию о разрешении конфликтов вы найдете в статье "How to: Resolve Conflicts" по адресу http://msdn2.microsoft.com/en-us/library/ms181433(VS.80).aspx.

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

Во избежание конфликтов, сделайте следующее:

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

Просмотр незавершенных изменений

1. В окне Source Control щелкните правой кнопкой решение, проект, папку или файл, для которых хотите просмотреть незавершенные изменения.
2. Выберите команду View Pending Changes.

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

tf status /format:detailed /user:*

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

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

• Дополнительную информацию о просмотре незавершенных изменений в своей рабочей области вы найдете в статье "How to: View and Manage All Pending Changes in Your Workspace" по адресу http://msdn2.microsoft.com/ en-us/library/ms181400(VS.80).aspx.
• Дополнительную информацию о просмотре незавершенных изменений в других рабочих областях вы найдете в статье "How to: View Pending Changes in Other Workspaces" по адресу http://msdn2.microsoft.com/en-us/library/ms181401(VS.80).aspx.
• Дополнительную информацию о команде tf status вы найдете в статье "Status Command" по адресу http://msdn2.microsoft.com/en-us/library/ 9s5ae285(VS.80).aspx.

Сборки

• Как с помощью TFS производить непрерывную сборку.

Как с помощью TFS производить непрерывную сборку

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

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

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

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

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

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

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

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

Возврат набора изменений, связанного с рабочим элементом

1. В Visual Studio откройте меню View, раскройте подменю Other Windows и выберите команду Pending Changes.
2. Введите комментарий, поясняющий характер изменений.
3. Щелкните значок Work Items, чтобы раскрыть список рабочих элементов, связанных с набором.
4. Обновите список рабочих элементов: выделите элемент и укажите нужное действие- Associate или Resolve (если возврат после правки подразумевает разрешение рабочего элемента).
5. Щелкните Check In, чтобы вернуть набор изменений на сервер управления исходным кодом.

Задание метки набора изменений

1. В окне обозревателя Source Control щелкните правой кнопкой папку с командным проектом и выберите команду Apply Label.
2. В раскрывающемся списке Version выберите вариант Changeset, введите номер в поле Changeset number и щелкните OK.
3. В диалоговом окне Apply Label введите имя метки и комментарий. Щелкните OK.

Просмотр свойств набора изменений

Производится с помощью команды tf changeset. Далее приведен пример команды, отображающей в диалоговом окне Details for Changeset свойства набора изменений под номером 1234: tf changeset 1234

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

Изменение свойств набора изменений

Используйте команду tf changeset, чтобы изменить комментарии и примечания, связанные с набором изменений. Приведенная ниже команда вызывает диалоговое окно Details for Changeset со свойствами набора под номером 1234 и обновляет поле комментария.

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

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

tf changeset /notes:"Code Reviewer"="C Davis";"Security Reviewer"="F Smith" 1234

Отмена набора изменений

Чтобы откатить набор изменений и удалить его с сервера управления исходным кодом, используется команда Tfpt rollback из комплекта Team Foundation Power Tool. В следующем примере производится откат набора изменений под номером 1234.

TFPT rollback /changeset:1234

Эта команда открывает окно Roll Back Changeset, в котором можно выбрать файлы из набора изменений для отката.

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

• Дополнительную информацию о команде tf changeset вы найдете в статье "Changeset Command" по адресу http://msdn2.microsoft.com/en-us/ library/w51xa47k(VS.80).aspx.
• Дополнительную информацию об извлечении наборов изменений вы найдете в статье "How to: Retrieve Old Versions of Files from Changesets" по адресу http://msdn2.microsoft.com/en-us/library/ms181416(VS.80).aspx.
• Загрузить инструмент Team Foundation Power Tool можно из источника, расположенного по адресу http://www.microsoft.com/downloads/details.aspx? FamilyID=7324C3DB-658D-441B-8522-689C557D0A79&displaylang=en.
• Дополнительные сведения об инструменте Team Foundation Power Tool вы найдете в статье "Power Toy: tfptexe" по адресу http://blogs.msdn.com/ buckh/archive/2005/11/16/493401.aspx.

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

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

По умолчанию, доступны следующие политики:

• Code Analysis Требует выполнения анализа кода перед возвратом.
• Test Policy Требует проведения тестов перед возвратом.
• Work Items Требует, чтобы с возвратом был связан один или несколько рабочих элементов.

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

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

1. В окне Team Explorer щелкните правой кнопкой ваш командный проект, раскройте подменю Team Project Settings и выберите команду Source Control.
2. Щелкните Check-in Policy и Add.
3. В списке Check-in Policy выберите вариант Code Analysis и щелкните OK.
4. Укажите нужный тип анализа кода, установив соответствующий флажок. При выборе варианта Enforce Code Analysis For Managed Code укажите требуемые правила в списке Rule settings for Managed Code Analysis.
5. Дважды щелкните OK.

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

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

• Обязательное добавление пользователями комментариев при возврате.
• Перед возвращением кода пользователи должны проводить дополнительные тесты.
• Пользователи не используют определенные директивы C#, чтобы подавить предупреждения документации XML.
• Проекты настроены так, чтобы во время компиляции генерировалась XML -документация.

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

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

• Дополнительную информацию о создании и использовании пользовательской политики возврата после правки вы найдете в разделе "Как создать пользовательскую политику возврата после правки в Visual Studio Team Foundation Server" этого курса.
• Дополнительную информацию о настройке политики возврата после правки вы найдете в статье "Walkthrough: Customizing Check-in Policies and Notes" по адресу http://msdn2.microsoft.com/en-us/library/ms181281 (VS.80).aspx.
• С примером кода, запрещающего определенные варианты программирования, можно ознакомиться по материалам статьи "Checkin Policy to Disallow Certain Patterns" по адресу http://blogs.msdn.com/jmanning/archi ve/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/ar-chive/2006/02/07/526778.aspx.
• Дополнительную информацию об использовании инструментов анализа кода вы найдете в статье "Guidelines for Using Code Analysis Tools" по адресу http://msdn2.microsoft.com/en-us/library/ms182023(VS.80).aspx.