Непрерывная интеграция с несколькими ветвями разработки в Subversion

Question

В проекте, над которым я работаю, мы используем SVN со стратегией «Стабильный ствол». Это означает, что для каждой найденной ошибки QA открывает bug ticket и назначает его разработчику. Затем разработчик исправляет эту ошибку и проверяет ее в ветке (от ствола, назовем это bug branch), и эта ветка будет содержать только исправления для этого конкретного bug ticket

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

Проблема в том, что мы используем trunk в качестве кодовой базы для нашей работы CI (особенно Гудзон ), и поэтому для всех коммитов на bug branch он пропустит ежедневную сборку он объединяется с trunk, когда мы решили выпустить новую версию программного обеспечения. Очевидно, что это побеждает цель иметь КИ.

Как правильно решить эту проблему?

Answer 1

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

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

Моя любимая стратегия - сделать что-то вроде этого:

    [begin work on 0.4 branch]
       |
       |
       v              
(*)---(*)-------(a)--(b)---(c)-- <-- Trunk is "unstable".
         \       |          |        Contains all commits.
    ver   \   [merge from trunk]     Developers commit to trunk.
<-- 0.3    \     v          v
            +---(a)--------(c)-- <-- Branch is "stable".
                                     Contains selected commits from trunk.
                                     Know beforehand what's going onto branch.

Теперь, когда вы будете готовы к выпуску:

[trunk]
(*)---(*)---(*)----------------------------[development continues]--->


[0.4 branch]                        No further development on branch unless
(*)---(*)---(*)---[0.4-release]     spot fixes are needed. Then re-tag (0.4.1)
                          ^         and re-release.
                          |         
                          |
                       [make tag on branch; release from stable branch,
                        not unstable trunk]

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

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

• Все, что обновляется, корректно интегрируется (trunk)
• Какой бы ни была ваша цель релиза, если вы перестанете работать сейчас, у вас все равно будет правильная и работающая (просто не полностью функциональная) сборка.

Answer 2

Вот что мы делаем (вдохновлено Контроль версий для нескольких гибких команд Хенрика Книберга):

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

CI работает во всех ветвях (ветки разработки, транк, ветки релиза).

Answer 3

Это звучит больно и слишком сложно (с точки зрения ветвления / слияния).

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

Answer 4

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

Или настроить ночные сборки на каждую ветку ошибок (что звучит как множество ночных сборок).

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

Answer 5

Я отвечаю на это много, и вот как IBM рекомендует это с ClearCase (UCM), и я делаю это в реальном мире:

 - Project
    |-  development mainline 
    |-  TAG: version-1.0 
         |- version-1.0-bugfix#123 
         |- version-1.0-bugfixes 
    |-  TAG: version-1.0-sp1 
         |- version-1.0-sp1-bugfix#234 
         |- version-1.0.sp1-bugfixes 
    |-  TAG: version-1.0-sp2 

Все, что не имеет префикса TAG, является веткой.

Answer 6

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

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

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