Какую стратегию ветвления следует использовать при разработке/обслуживании веб-приложения?

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

То, как я вижу это, есть две основные стратегии ветвления: "ветвь по выпуску" и "ветвь по признаку".

"Филиал по версии" . Разработка происходит на багажнике. Когда время релиза близко, для этой версии создается ветка. Затем эта ветвь стабилизируется/тестируется и, наконец, производится выпуск. После релиза ветвь объединяется обратно в багажник, сохраняя при этом освобожденную ветвь для исправления ошибок. Применяется исправление ошибок, затем оно сливается в туловище (если разработка на туловище не затмила ошибку другими способами). Новые функции добавляются в магистраль и не влияют на ветвь релиза. Когда приближается новое время выпуска, создается новая ветвь release a.s.o.

"Филиал по функциям" . Строка всегда является "производственной" ствол (код, который является живым). Исправления исправляются непосредственно в багажнике. Функции для следующей версии разрабатываются в ветких функций. Исправления периодически объединяются в ветки функций. Когда приходит время релиза, ветки признаков объединяются в багажник, и цикл жизни продолжается.

Теперь, как я вижу, большая практическая разница между этими двумя стратегиями заключается в том, что "по версии" позволяет вам скомпоновать различные производственные версии вашего программного обеспечения (когда клиент A имеет версию 1 и клиентскую версию B версии 1.5, клиент является платным клиент в этом случае). В отличие от стратегии "по функциям" вы можете поддерживать только текущую производственную версию (все клиенты используют последнюю версию).

Так как в типичном веб-приложении все клиенты используют ту же самую "последнюю" версию (поскольку все они имеют доступ к одному и тому же серверу), я бы предположил, что подход "по функциям" наиболее часто используется. Это устраняет необходимость объединения "по иерархии", скажем, когда исправление должно быть применено ко всем 3 версиям выпуска.

Итак, мой текущий статус заключается в том, что я должен пойти с функцией "branch by feature". Если это имеет значение, моя команда не очень квалифицирована.

Ответ 1

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

Если ветка по-умолчанию для вас означает наличие нескольких ветвей на ходу одновременно, я бы избегал ее, как чумы. Больше веток означает больше слияния, что само по себе является больным, и больше адский ад. Гораздо лучше сделать непрерывную интеграцию в одну кодовую линию.

Если ваш процесс развертывания более активен, чем ветвь, протестируйте, перейдите в прямом эфире, тогда преимущество разветвления по-разному состоит в том, что вы можете иметь несколько ветвей разблокировки сразу, в разные фазы: один из них живет и становится багфиксом необходимый, а другой - стабилизированный, проверенный, проходящий прием и т.д., в то время как развитие продолжается на стволе. Если у вас есть живая ствол, с другой стороны, как только вы объедините филиал функции, чтобы просмотреть его вживую, вы потеряли способность исправлять ошибки в текущей живой системе. Слияние свойств функции становится точкой без возврата.

Ответ 2

Какое программное обеспечение вы разрабатываете? Термоусадочная пленка? Проект с открытым исходным кодом? Если это так, то перейдите с подходом "ветвь к выпуску" или "неустойчивый багажник". Особенно, если ваши циклы выпуска раз в шесть месяцев до года.

Но если вы поддерживаете веб-проект, который имеет изменения, происходящие на более коротких частотах, например, раз в несколько недель или менее, переходите к подходу "branch by feature" или "stable trunk". Проблема с этим подходом заключается в объединении нескольких изменений функций, которые имеют радикальные изменения, делают процесс слияния менее интересным. Это действительно тяжело.

Но оба они хорошо работают, но что, если вам нужны оба? То есть, у вас есть проект, который развертывает, говорит один раз каждые две недели с большими изменениями функций, но вы обнаружите, что у вас есть ряд исправлений ошибок, которые вы не можете дождаться, когда эти изменения функций будут готовы. Магистраль - это ваша релизная ветвь с подходом "от ветки". Что делать, если вы можете получить оба релиза и добавить свою собственную ветку?

Отметьте эту запись в блоге от CollabNet Bob Archer. Его стратегия Agile Release дает вам лучшее из того и другого. Я использовал это. Он чрезвычайно гибкий. Несмотря на то, что Боб не показывает его на диаграмме, вы можете одновременно иметь несколько ветвей выпуска. Это означает, что у вас может быть одна ветвь релиза, готовая к развертыванию, и другая, которая готовится к окончательным проверкам QA. Но нужно рассмотреть две вещи:

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

Во-вторых, вам понадобится хорошее понимание готовых изменений и тех, которые должны быть. Управление релизами является ключом к тому, чтобы эта работа работала как часы. Каждая функция, когда она будет готова, должна быть привязана к ветки релиза и объединена с ней.

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

Ответ 3

Эти варианты не являются взаимоисключающими - используйте оба. Они решают разные проблемы:

"От ветвления по версии" - ветвь release используется для обеспечения возврата к источнику, используемому для создания текущей версии в реальном времени (или предыдущих выпущенных версий), в то время как следующая версия находится в разработке. Например. Это делается для того, чтобы внести изменения в версию выпуска для исправлений ошибок или функций обратной связи из текущей соединительной линии развития.

"Филиал по функции" - используется для поддержания стабильной соединительной линии разработки в любое время, что особенно полезно для нескольких разработчиков и для экспериментальных "возможно" функций.

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

Я настоятельно рекомендую использовать современные DVCS, такие как git или Mercurial. Они ориентированы на параллельную разработку, поэтому они сохраняют изменения по-другому, чем старые системы, что делает процесс слияния более простым.

Ответ 4

С риском запутать вас дальше: вы можете разблокировать ветки и внести изменения в ветки функций. Эти вещи не являются взаимоисключающими.

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

Итак, я бы сказал, что ваш выбор подходит.

Ответ 5

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

для каждой новой функции создайте ветку для этой функции.
Когда все работает, объедините его в ветвь staging и разверните на промежуточном сервере (у вас есть один из них, правильно?)
Как только мы уверены, что клиент доволен тем, что на этапе, мы объединяем промежуточную ветку в производственную ветвь, помечаем ее как нечто вроде production_release_22 или production_release_new_feature_x, а затем развертываем этот тег на производственный сервер.

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

Это сработало для меня до сих пор.