Subversion Branch/Trunk Best Practice - поддержание актуальности ветки?
Моя команда разработчиков уже давно работает с Subversion. Способ управления стволом и ветвями заключается в следующем:
Мы (почти) всегда выпускаем из багажника
Каждый релиз получает свою ветку.
Когда релиз готов к QA, мы объединяем ветвь обратно в ствол и создаем новую ветвь для следующего выпуска.
Разработчики работают независимо от магистрали или ветви, но веток для разработчиков нет.
В последнее время у нас было несколько кошмарных сессий, частично из-за серьезных изменений в приложении. Они не всегда проходят гладко, и проблемы иногда всплывают во время QA, где subversion слилась не совсем правильно.
Одним из решений может быть регулярное объединение изменений в соединительную линию в ветку релиза, скажем, еженедельно, чтобы гарантировать, что самые последние изменения в стволе находятся в ветке. Конфликты могут быть исправлены ближе к реальному времени.
Каков ваш опыт с этой проблемой? Есть ли стандартная лучшая практика? Кроме того, у вас есть хороший способ отследить, какие ревизии были объединены в ветке (достойные комментарии в Subversion, вероятно, могли бы справиться с этим).
5 ответов
Во-первых, я не думаю, что есть универсальное решение для всех ветвей и выпусков кода. Но коснемся нескольких ваших точек зрения с моей точки зрения:
Да, я бы чаще сливал изменения из транка в ветку релиза. Меньшие куски всегда будут более управляемыми, чем одна большая интеграция. И, конечно, это означает, что вы работаете с самым последним наиболее стабильным кодом.
Упреждающе учите людей правильно сливаться. Разработчик, который внес изменение, должен выполнять (или быть тесно связанным с) слияние. Поймите, что вы принимаете, и как это должно выглядеть, когда закончите. Я слишком часто вижу, как люди проводят интеграцию, не зная, что они делают и чего они ожидают в результате.
Возможно, вы хотите иметь ветку интеграции, которая не является магистральной. Это может быть проверено ежедневно и любые проблемы, обнаруженные здесь, прежде чем они пойдут и сломать багажник и напугать всех
Итак, предположим, что у меня есть ваша модель прямо здесь: вы разрабатываете серьезные изменения в проекте в ветке (вне ствола), которая может стать довольно старой.
Вы продолжаете делать другие разработки на транке, который всегда содержит "живое" программное обеспечение, так что эти изменения являются незначительными обновлениями и исправлениями ошибок. У вас возникают проблемы, когда вы сливаете монументальную ветку разработки обратно в ствол.
С этой моделью вы можете эффективно управлять только двумя одновременно действующими версиями продукта, которых может быть достаточно на данный момент, но в любом случае вы можете укусить вас и ухудшить, если вам когда-нибудь понадобится управлять 3 или 4 версиями. Могу ли я предложить изменить способ работы?
Есть ветка Версия для каждого выпуска. Это должно быть ответвление от ствола (при любой ревизии). Единственный способ изменить ветку версии - это объединить ревизии из ствола.
Это означает, что вы можете работать в основном на транке, а не в большой ветви разработки. Вы также применяете свои исправления ошибок непосредственно к стволу - таким образом у вас нет никаких серьезных проблем интеграции, сохраняемых для следующего выпуска. Чтобы выпустить исправления ошибок в предыдущих версиях, просто объедините требуемые версии ствола в соответствующую ветку Version.
Таким образом, вы можете хранить все, что вы хотите выпустить в ветке, но только фактически выпускать то, чем вы довольны, потому что это все, что вы сливаете в ветку версий.
Вы по-прежнему можете использовать ветки разработки, если вам это нужно, но вы можете сохранять их целевыми и небольшими, возможно, отдельными функциями, а не большими проектами.
Это позволит вам разумно управлять несколькими версиями и следить за тем, что есть в каждом выпуске, используя svn merge-info.
Наш опыт состоит в том, чтобы четко дифференцировать:
- ветка развития
- филиал консолидации (филиал, используемый для консолидации разработки, мы обязательно перейдем к производству
Магистраль предназначена только для записи стабильно выпущенной версии, из которой мы можем разветвляться.
В "ветке разработки" мы можем управлять важными изменениями, включая некоторые, которые не попадут в следующий выпуск (потому что слишком сложны, не готовы вовремя, зависят от других поздних разработок,...)
Ветвь консолидации представляет последние шаги (обратите внимание на множественное число), необходимые для завершения выпуска. Это происходит после встречи, на которой проверяются все функции, которые необходимо было доставить.
Мы объединяем в "отрасль консолидации" только то, что обязательно введем в производство. Мы продолжаем эту ветку до финального релиза.
Во-первых, я полностью согласен с предыдущими респондентами, что не существует единого решения, подходящего для всех.
В нашем случае у нас много сравнительно небольших приложений, в каждом из которых, как правило, только один разработчик. Когда мы участвуем в совместной разработке, обычно бывает от 2 до 4 разработчиков.
Наша общая политика:
- Ствол содержит текущее состояние проекта;
- Мы используем ветки для разработки новых функций, исправления ошибок и т. Д. Ветви объединяются обратно в ствол после завершения;
- Чтобы освободить, мы создаем тег из текущего транка и выпускаем тег.
Энди также подчеркнул важный момент, который необходимо подчеркнуть: "Упреждающе учите людей, как правильно сливаться". Многие, если не большинство наших проблем, похоже, возникают из-за плохой практики слияния.
Полностью согласен с Энди: нет единого решения, подходящего для всех, но проблема не в том, чтобы поддерживать ветку вашего релиза в актуальном состоянии, а наоборот.
Хороший контроль изменений должен держать вашу ветвь от нестабильной. Проблемы со стробированием должны быть исправлены в ветке релиза, а затем немедленно объединены со стволом. Будьте готовы к тому, что это "слияние" будет нетривиальным, проблема с выпуском релиза может даже не существовать в транке, но вам все равно нужно выполнить анализ и протестировать его.
Это звучит из того, что вы говорите, что вы развиваетесь на своей ветке, а затем сливаетесь сразу со своим стволом, как раз перед тем, как отпустить, и просто скрестите пальцы. Интересно, сколько ошибок вы вносите, делая это.