2013-10-10 2 views
0

В этом месяце мы начнем новый проект, и я хотел бы получить идеи и мнения по стратегии ветвления, которую мы будем внедрять. Проект будет составлять 1 год, а развертывание производства произойдет только к концу проекта. Мы будем делать итеративное развитие (1 месяц на итерацию), поэтому это означает, что мы отбросим функции в тестовую среду в конце каждой итерации для тестирования QA. Наша стратегия ветвления:Ветвянная стратегия для тестовой среды

Магистраль - Все развитие будет происходить на стволе. Филиал функций - ветви с внешней стороны будут созданы на основе потребностей для разработки больших функций, которые могут быть разбиты, если они сделаны на магистрали. Разделительные ветви QA. В конце каждой итерации будет создана ветвь соединительной линии. Эта ветка (которая включает номер версии) будет выпущена в тестовую среду. Все критические и блокирующие ошибки, обнаруженные в этой версии, будут исправлены на этой ветке, и исправления должны быть объединены с trunk. Некритические/тривиальные ошибки не будут устранены в ветви релиза QA и будут фиксированы только в магистрали, так как ветвь релиза QA будет выброшена после окончания следующей итерации, когда новая ветка релиза будет создана из внешней линии. Производственный отдел - это будет последняя ветка выпуска QA в конце проекта. Это будет помечено, и все исправления ошибок в производстве будут на этой ветке и объединены с багажником. Является ли это правильной стратегией разветвления? Есть ли что-то еще, что мы упустили, чтобы рассмотреть?

Мы используем SVN.

Спасибо!

ответ

0

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

+0

Это план. Области функций будут для изменений, которые будут сильно отличаться от архитектуры, дизайна, структуры или функции. Спасибо за ваш комментарий. – rro

Смежные вопросы