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

Question

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

На мой взгляд, есть две основные стратегии ветвления: «ветвление за выпуском» и «ветвление по функции».

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

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

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

Поскольку в типичном веб-приложении все клиенты используют одну и ту же «последнюю» версию (поскольку все они обращаются к одному и тому же серверу), я бы предположил, что подход «по функциям» являетсянаиболее часто используемый.Это устраняет необходимость слияния «по всей иерархии», например, когда необходимо применить исправление ко всем трем версиям релиза.

Так что мой текущий статус заключается в том, что я должен использовать «ветвление по функциональности».Если это имеет значение, моя команда не очень опытна.

Answer 1

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

Но если вы поддерживаете веб-проект, в котором изменения происходят на более коротких частотах, например, раз в несколько недель или меньше, то используйте подход «ветвление по функциональности» или «стабильный ствол». Проблема с этим подходом состоит в том, что интеграция нескольких изменений функций, которые имеют широкие изменения, делает процесс слияния менее увлекательным. Это действительно очень сложно.

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

До сих пор это работало довольно хорошо для меня.