Subversion с непрерывной интеграцией

Question

Извините, если ответы на этот вопрос уже существуют, я их еще не нашел.

Я являюсь членом команды веб-разработчиков, мы поддерживаем веб-портал. Управление релизами работает с Subversion. Вот как я работаю при добавлении новых функций на портал:

• Создать новую ветку, скопировав Магистраль
• Развивайся в этой ветке
• Периодически объединять обновления из магистрали в эту ветвь (я хочу знать, не нарушит ли Framework-Changes мой код, прежде чем он перейдет к UAT / Integration, например)
• Реинтегрируйте Ветвь в Ствол, чтобы позволить ему жить

Теперь у нас проблема с непрерывной интеграцией:

• Периодический запуск каждые X недель
• Существует несколько филиалов, которые планируется запустить в разные даты
• Каждые X часов в день сервер интеграции выполняет проверку соединительных линий и объединяет в нее все филиалы (которые должны явно идти в систему интеграции)
• Обновления Транка, которые были объединены в каждую Ветвь (см. Выше), теперь генерируют Древовидные Конфликты

Какая лучшая практика для этого? Реинтеграция не работает для объединения нескольких ветвей, потому что, как только одна ветка интегрируется, рабочая копия больше не чистая. Тем не менее, непрерывная интеграция должна быть как-то возможна ...

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

Спасибо за любую помощь.

Answer 1

То, что вы описали, это не непрерывная интеграция из-за следующего требования:

Каждые X часов в день сервер интеграции выполняет проверку соединительных линий и объединяет все ветви (что должноявным образом перейдите в Интеграционную систему)

Реальный Continuous integration включает следующие шаги:

• Обновление исходного кода из одной конкретной ветви (trunk, например).
• Создание исходного кода, создающего артефакт сборки, который может быть выполнен или развернут.Иногда этот этап включает также проведение юнит-тестов и проверок.
• Показывает статус сборки, независимо от того, была она успешной или нет: зеленая или красная.

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

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

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

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

Подводя итог,

1. Исключить merge all branches шаг из вашего процесса (это не следует делать автоматически).
2. Выполнить объединение вручную *Вместо 1038 *.
3. Если вы уверены, что вам нужно постоянно иметь филиалы, настройте непрерывную интеграцию для таких каждой ветви отдельно .
4. В противном случае (вам не нужно постоянно хранить ветки, и они могут быть легко реинтегрированы в родительскую ветвь после завершения разработки) уменьшить количество ветвей до минимума .

Удачи!