Модель ветвления TFS 2010 для внутреннего приложения

Question

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

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

После долгих исследований мы решили использовать главную магистраль, от которой мы разветвляем две дочерние ветви: Разработка и Обслуживание (или Исправление ). Как представлено в руководстве, ежедневная разработка будет происходить в ветви Разработка , откуда мы выполняем обратную интеграцию (RI) каждый раз, когда у нас есть функции, готовые для следующего выпуска. Прямо перед выпуском обратная интеграция прекратится, и код стабилизируется в ветви Main . После выхода из Main будет прямая интеграция (FI) из Main в Development и Maintenance . < / p>

Любое исправление произойдет только в Техническом обслуживании , и в зависимости от исправления (например, если мы хотим сохранить его в базе кода), мы выполним RI в Main и оттуда ФИ в Разработку .

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

Например, мы бы также рассмотрели возможность создания другой ветки, Release , где стабилизация кода происходит перед выпуском в производство (вместо работы непосредственно в Main ) и конечно, мы выпустим отсюда в рабочую среду и сделаем RI в Main , а затем FI для разработки и обслуживания , но мы не уверены, принесет ли это пользу или просто усложнит?

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

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

Answer 1

Читали ли вы документацию по разветвлению TFS ALM Rangers?То, что вы предлагаете, очень похоже на их «Стандартный план ветвления», хотя они поощряют наличие и выпуска, и ветки «пакета обновления» (во многом как ваши ветки выпуска и обслуживания выше).

http://vsarbranchingguide.codeplex.com/

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

Еще одна вещь, которую следует рассмотреть, - это ступенчатая модель, в которой вы создаете новые ветки Dev в каждом выпуске и фиксируете старую как выпуск.Это позволит избежать RI, так как вы можете просто исправить старый и при необходимости внести исправление в новую ветку Dev.Я тоже работал над этой моделью, и это было здорово.