Спонсор: Microsoft
Опубликован: 25.03.2010 | Доступ: свободный | Студентов: 805 / 25 | Оценка: 4.43 / 3.71 | Длительность: 10:46:00
Дополнительный материал 1:

Руководства

< Лекция 18 || Дополнительный материал 1: 12345678910111213 || Дополнительный материал 2 >

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

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

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

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

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

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

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

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

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

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

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

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

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

  • для внутренних этапных сборок, например, для альфа-версии;
  • для сборки, созданной после интеграции ветви или внешней зависимости. Чтобы облегчить поиск сборки в будущем и без проблем разобраться, что она собой представляет, соблюдайте соглашение об именах. Метки должны четко отражать содержание. Например, метка "AlphaBuild_200701122 создана на основе правила "ИмяСборки_Дата".

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

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

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

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

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

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

  • Main - ветвь интеграции
    • Source
    • Другие папки ресурсов
  • Releases - контейнер для ветвей сопровождения
    • Release 1 - ветвь сопровождения
      • Source

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

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

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

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

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

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

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

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

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

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

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

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

  • Development - контейнер для ветвей разработки.
    • Ветвь разработки.
      • Вложенная ветвь первого уровня.
        • Вложенная ветвь второго уровня.
  • Main - ветвь интеграции.
    • Source.
    • Другие папки ресурсов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< Лекция 18 || Дополнительный материал 1: 12345678910111213 || Дополнительный материал 2 >
Александр Будник
Александр Будник
Израиль, Иерусалим
Pavel Pelevin
Pavel Pelevin
Украина, Одесса