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

Question

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

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

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

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

Что надлежащий путь состоит в том, чтобы устранить эту проблему?

8

version-control continuous-integration hudson

задан John Feminella 6 July 2012 в 16:32

6 ответов

Выполняйте еженощное слияние с «нестабильным-злым-двойным стволом», которое объединяет все ответвления жуков с злым-двойным стволом.

Или настройте ночные сборки для каждой ветки с ошибками (что похоже на множество ночных сборок).

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

1

ответ дан 5 December 2019 в 08:22

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

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

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

0

ответ дан 5 December 2019 в 08:22

Вот что мы делаем (на основе Version Control for Multiple Agile Teams Хенрика Книберга):

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

_{(источник: infoq.com )}

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

5

ответ дан 5 December 2019 в 08:22

Я часто на это отвечаю, и вот как 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 - это ветка.

0

ответ дан 5 December 2019 в 08:22

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

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

2

ответ дан 5 December 2019 в 08:22

Другие вопросы по тегам:

version-control continuous-integration hudson

Похожие вопросы:

score 12 · Accepted Answer

Как вы заметили, одна из целей использования ветки - отделить определенные колебания кода от исправления заявок и разработки функций от основной ветви. Но как только функция или заявка будут готовы, вы должны снова объединить их. В 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]

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

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

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