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

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

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

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

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

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

• Вводный курс по ветвлению и слиянию вы найдете в статье "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/ms 181423(VS.80).aspx.

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

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

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

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

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

• Когда выполнять ветвление Когда вы готовы к выпуску, соберите все в главную ветвь ( Main ), а затем создайте ветвь выпуска ( Release ), целью которой будет стабилизация приложения перед выпуском.
• Когда не следует выполнять ветвление Если каждому выпуску соответствует отдельный проект TFS, вы можете продолжать разработку, создав новый проект, не выполняя ветвление текущего проекта.
• Разрешения в ветви
  • До выпуска Предоставьте разрешения на чтение и запись всем разработчикам.
  • После выпуска Предоставьте разрешения на чтение и запись разработчикам, принимающим участие в работе над исправлениями. Остальным достаточно разрешения на чтение.
• Частота производства сборок в ветви Сборки производятся по мере необходимости.
• Тесты в ветви Прекращаются после выпуска.

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

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

• Вводный курс по ветвлению и слиянию вы найдете в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/ aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/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.
  • Другие папки ресурсов.
• 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/ms 181423(VS.80).aspx.

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

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

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

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

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

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

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

• Вводный курс по ветвлению и слиянию вы найдете в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/ aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/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/ms 181423(VS.80).aspx.

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

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

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

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

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

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

Ветвление позволяет вести разработку функций параллельно. При этом вся активная разработка выполняется в ветвях функций, а последующая интеграция кода - в ветви 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/ms 181423(VS.80).aspx.

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

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

• Development - контейнер для ветвей команд.
  • Team 1 - ветвь команды.
    • Source.
  • Team 2 - ветвь команды.
    • Source.
• Main - главная ветвь сборки.
  • Source.
  • Другие папки ресурсов.

Учитывайте следующие рекомендации по работе с ветвями команд:

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

Не пренебрегайте ветвлением команд, чтобы команды могли работать над своими задачами одновременно. Ветви помогают изолировать ошибки команды, а также позволяют командам двигаться к различным вехам. Вся активная разработка должна проводиться в ветвях команд с последующим переносом в главную ветвь ( 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.

Как с помощью ветвления изолировать внешние зависимости

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

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

• External - ветвь внешней зависимости.
  • Source.
• Main - главная ветвь сборки.
  • Source.
  • Другие папки ресурсов.

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

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

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

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

• Вводный курс по ветвлению и слиянию вы найдете в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/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/ms 181423(VS.80).aspx.