Subversion Branch / Trunk Best Practice - поддержание актуальности ветки?

Question

Моя команда разработчиков уже давно работает с Subversion. Способ управления стволом и ветвями выглядит следующим образом:

• Мы (почти) всегда выпускаем из багажника

• Каждый выпуск имеет собственную ветку.

• Когда релиз готов для QA, мы объединяем ветвь обратно в ствол и создаем новую ветвь для следующего выпуска.

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

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

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

Какой у вас опыт с этой проблемой? Есть ли стандартная лучшая практика? Кроме того, у вас есть хороший способ отследить, какие ревизии были объединены в ветку (достойные комментарии в Subversion, вероятно, могли бы справиться с этим).

Answer 1

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

• Да, я бы чаще сливал изменения из транка в ветку релиза. Меньшие куски всегда будут более управляемыми, чем одна большая интеграция. И, конечно, это означает, что вы работаете с самым последним наиболее стабильным кодом.

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

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

Answer 2

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

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

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

Иметь ветку Version для каждого выпуска. Это должно быть ответвление от ствола (при любой ревизии). Единственный способ изменить ветку версии - это объединить ревизии из ствола.

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

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

Вы все еще можете использовать ветки разработки, если вам нужно, но вы можете сохранять их целевые и небольшие, возможно, отдельные функции, а не крупные проекты.

Это позволит вам разумно управлять несколькими версиями и следить за тем, что есть в каждом выпуске, используя svn's merge-info.

Answer 3

Наш опыт заключается в четкой дифференциации:

• ветка разработки
• филиал консолидации (филиал, использованный для консолидации разработки, мы обязательно перейдем к производству

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

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

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

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

Answer 4

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

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

Наша общая политика:

• Транк содержит текущее состояние проекта;
• Мы используем ветви для разработки новых функций, исправления ошибок и т. Д. Филиалы объединяются обратно в ствол после завершения;
• Для освобождения мы создаем тег из текущего транка и освобождаем тег.

Энди также подчеркнул важный момент, который необходимо подчеркнуть: «Упреждающе учите людей, как хорошо сливаться». Многие, если не большинство наших проблем, похоже, возникают из-за плохой практики слияния.

Answer 5

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

Хороший контроль за изменениями должен предохранять вашу ветвь от нестабильности. Проблемы со стробированием должны быть исправлены в ветке релиза, а затем немедленно объединены со стволом. Будьте готовы к тому, что это «слияние» будет нетривиальным, проблема с выпуском релиза может даже не существовать в транке, но вам все равно нужно выполнить анализ и протестировать его.

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