Имеет ли смысл эта стратегия ветвления в экосистеме веб-разработки?

Question

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

Проблема заключается в новой системе ветвления , которую мы собираемся принять в ближайшем будущем. На работе мы разрабатываем преимущественно веб-приложения (электронная коммерция, cms, классифицированные, специального назначения) и некоторые веб-сайты на php, а наш vcs - svn .

Это новая модель, которую мы хотим принять:

Магистраль : всегда развитие

Постановка (ветвь): ветвь, созданная для тестирования новых функций на удаленном окружении (та же система, что у живого, действительно тот же сервер ..)

Live (ветка): ветка для жизни.

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

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

Вставьте багажник в постановку, чтобы подготовиться к новым функциям, которые скоро появятся; а потом? как мы можем получить эту постановку в живой ветке? Мы должны пройти из сундука?

Теперь стратегия такова:

Магистраль : это живая версия

Филиал для каждая функция

Исправлено живое исправление для транка, затем передано в ветви

Staging - это рабочая копия, которая переключается на ветку в конце разработки функции, перед слиянием обратно в транк.

Но у этого метода есть некоторые недостатки:

• всегда переключается ..

• нет возможности проверить две параллельные ветви

Что вы думаете о новой стратегии?

Answer 1

У нас есть ветки / функция для разработки крупных функций, релизы / x.y для живых выпусков (в основном, в виде тегов, но иногда потому, что одновременно запущено более одного выпуска), а транк используется в качестве промежуточного этапа выпуска. Исправления ошибок выполняются в транке и выборочно передаются в любые ветви или выпускают сборки по мере необходимости.

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

Вы не говорите, какую систему контроля версий вы используете, но у большинства из них есть предложенная стратегия (http://svnbook.red -bean.com / ru / 1.0 / ch05s04.html # svn-ch-5-sect-6.1) например.