Модель ветвления TFS 2010 для внутреннего приложения - PullRequest
1 голос
/ 12 января 2012

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

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

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

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

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

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

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

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

1 Ответ

4 голосов
/ 12 января 2012

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

http://vsarbranchingguide.codeplex.com/

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...