Идеи для стратегии ветвления для веб-приложения?

Question

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

Вот ситуация:

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

Имея это в виду, я предложил 4-х веточную систему:

• Dev - для текущих последних разработок
• QA - для внутреннего контроля качества
• UAT - для предварительного тестирования
• Production - для клиентов

Слияние будет осуществляться следующим образом:

• Изменения в ветви QA будут сделаны путем объединения FROM Trunk
• Изменения в ветви UAT будут сделаны путем объединения FROM UAT
• Изменения в производственной ветви будут внесеныот Merging ИЗ ПРОИЗВОДСТВА

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

• Сборки из ветви Dev будут развернуты в среде Dev
• Сборки изветвь QA будет развернута в среде QA
• сборки из ветви UAT будут развернуты в среде UAT
• сборки из ветви Production будут развернуты в производственной среде

Итак, что вы думаете?Я смутно на ходу?

Answer 1

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

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

На codeplex есть руководство по стратегии ветвления TFS.

http://tfsbranchingguideiii.codeplex.com/

удачи

Answer 2

Ваш подход хорош. Но из моего прошлого опыта единственные предложения, которые я могу сделать, - сделать версию репозитория (1.1.1_C0, 1.1.0_B0 или 1.0.0_A0) зависимой, а не окружающей средой (Dev, UAT, PROD) зависит в отраслях. Это работает хорошо или нам. Мы помечаем каждую версию в зависимости от того, на какой стадии разработки находится код.