Ветвление/слияние SVN с функциональной веткой и производственной веткой

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

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

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

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

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

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


person Bill K    schedule 06.09.2013    source источник
comment
Вы хотите объединить функцию с производством, не объединяя ее со стволом?   -  person maxim1000    schedule 07.09.2013
comment
Вам больше повезет с Subversion 1.8. Он имеет некоторые значительные улучшения в механизме слияния, особенно для более продвинутых вариантов использования, таких как слияния одноуровневых элементов.   -  person randy-wandisco    schedule 10.09.2013
comment
Лично я бы относился к стволу как к королю: там не происходит никакого развития, только слияние из веток функций, созданных вне ствола. Вы проводите свой обычный контроль качества в функциональной ветке, и как только она будет подписана, вы сливаете ее обратно в основную ветку. Затем пометьте ствол и отправьте его в производство. Новая функция ответвляется от ствола, и цикл начинается снова. Если есть ошибка, которая должна быть исправлена ​​немедленно, создайте ветку исправления ошибки вне основной ветки в помеченной ревизии, исправьте ошибку, проведите контроль качества, затем снова объедините ее, пометьте и выпустите в производство. Очень легко следовать этому рабочему процессу после того, как вы сделаете несколько релизов. Просто мои два цента.   -  person Sameer Singh    schedule 10.09.2013
comment
@Sameer Это похоже на процесс, используемый для ветки Production, но в другом месте, с которым я полностью согласен, но в какой момент вы тестируете интеграцию своих функций (не тесты разработчиков, а разрешение QA тестировать всю функцию) установить перед отправкой?)   -  person Bill K    schedule 19.09.2013
comment
Моя команда практикует Agile. У нас есть ежедневные схватки, еженедельные спринты, а через две недели мы обычно проводим контроль качества, объединяем пост-подписку и развертываем в продакшене. На первой схватке в понедельник команда выбирает несколько ошибок и функций на неделю, а на каждой последующей схватке команда проверяет достигнутый прогресс. Через две недели (фактически, ко второй среде) у нас есть набор выполненных задач (баги исправлены, фичи добавлены), которые можно отправлять в QA. К пятнице мы получим одобрение и сможем объединиться и развернуться в рабочей среде.   -  person Sameer Singh    schedule 20.09.2013
comment
Мы также используем семантическое управление версиями, чтобы наши сборки и выпуски имели номера версий, которые выглядят следующим образом: MAJOR.MINOR.MICRO.REVISION. Надеюсь это поможет.   -  person Sameer Singh    schedule 20.09.2013


Ответы (1)


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

  1. Describe your branching (and merging) strategies. You cannot easily mix all of them, and it is difficult for developers to know which strategy is used where, so documentation and communication is here key. See the following resources:
  2. You will use the following:
    • Release branch for the production release, patches are developed directly there. For each patch, you have to decide, if that patch should be available (in the same form) in the next release.
    • Используйте ствол для основного развития. Все, в чем вы уверены, что будет в следующем релизе, должно быть разработано на стволе. Не объединяйтесь из ствола в (освобождение) ветку. Никогда!!
    • Используйте ветки функций только в том случае, если вы не уверены, появится ли функция в следующем выпуске. Ветки функций (в Subversion) намного сложнее, чем, например. в Git, поэтому должна быть причина для их использования. Регулярно объединяйте все изменения из основной ветки в ветку функций и повторно интегрируйте только в конце, когда функция будет интегрирована в основную ветку (чтобы перейти к следующему выпуску).
  3. Find the right point in time for doing the branching and merging:
    • Branching: When is a stable release branch necessary (for integration to the next release), and when can development start for the following release (then on the trunk again)?
    • Слияние: Когда лучше всего объединять изменения: Немедленно, когда изменение свежее; регулярно время от времени; (надеюсь, нет) только один раз в конце.

Ваши ветки со временем будут развиваться следующим образом:

  1. Вы начинаете с транка (и только с транка) для версии 1.0, вашего первого релиза.
  2. Вы разветвляете ствол, когда хотите провести интеграционное тестирование для версии 1.0, и начинаете разработку для выпуска 1.1 (на магистрали).
  3. Вы поставляете релиз 1.0, а затем предоставляете патчи прямо из ветки.
  4. Вы разветвляете ствол, когда хотите провести интеграционное тестирование для выпуска 1.1, и начинаете разработку для выпуска 1.2 (или 2.0) на стволе.
  5. ... и так далее ...

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

person mliebelt    schedule 07.09.2013
comment
Есть ли способ справиться со случаем, когда функция зарегистрирована в транке, другие ветки функций объединяют эти изменения, а затем повторно интегрируются в магистраль, но затем вы хотите отправить без первой функции? - person Bill K; 19.09.2013
comment
Просто играл с SVN, и я думаю, что ответил на свой вопрос - Отмена изменений, сделанных этой версией, кажется, делает свою работу довольно хорошо. - person Bill K; 19.09.2013