Многофункциональные ветви и непрерывная интеграция

Question

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

У нас есть стабильныймагистральная / магистральная ветка и создание веток для функций.Каждый разработчик будет поддерживать свои собственные ветки функций в актуальном состоянии, регулярно объединяясь из магистрали в свою ветку.Однако вполне возможно, что две или более ветвей функций могут быть созданы и работать в течение нескольких недель или месяцев.За это время многие версии программного обеспечения могут быть развернуты.Это где моя путаница возникает.

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

Answer 1

В правильном CI нет ветвей функций.Используйте функцию для переключения .

Answer 2

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

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

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

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

Answer 3

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

Люди git делают то же самое, перебирая ветви функций в верхней части главной ветви перед отправкой функции.

Answer 4

По моему опыту с CI, то, как вы должны поддерживать свои функции в актуальном состоянии, с изменениями в основной строке, как предлагали другие.Это работало на меня несколько выпусков.Если вы используете Subversion, убедитесь, что вы слились с включенной историей слияния.Таким образом, когда вы пытаетесь объединить свои изменения обратно в линию, вам будет только нужно объединить изменения функции со строкой, не пытаясь разрешить конфликты, которые ваша функция может иметь с основной линией.Если вы используете более продвинутые VCS, такие как git, первое слияние будет ребазой, а второе - слиянием.

Существуют инструменты, которые могут помочь вам сделать все более плавно, как это Ветки функцийс бамбуком

Answer 5

Теперь есть несколько хороших ресурсов, показывающих, как объединить ветви CI и функции. Bamboo или Feature Branch Notifier - некоторые способы поиска.

И this - еще одна довольно длинная статья, показывающая плюсы так называемого распределенного CI. Ниже приводится одна выдержка, объясняющая преимущества:

Распределенный CI имеет преимущество для непрерывного развертывания, поскольку он поддерживает чистую и стабильную ветвь Mainline, которую всегда можно развернуть в Production. Во время процесса централизованного CI будет существовать нестабильная магистраль, если код не интегрируется должным образом (поврежденная сборка) или если есть незавершенная работа. Это очень хорошо работает с планированием выпуска итерации, но создает узкое место для непрерывного развертывания. Прямая линия от ветки разработчика до Production должна поддерживаться в чистоте на компакт-диске. Распределенный CI делает это только с помощью , позволяя помещать готовый производственный код в Mainline .

Одна вещь, которая все еще может быть сложной, - это сохранить сборку ветки, чтобы она не загрязняла ваш репозиторий двоичных файлов, выдвигая его сборки веток. Бамбук, кажется, решает эту проблему, но не уверен, что с Дженкинсом так же легко.

Answer 6

Функциональные ветви возвращаются в основную линию, и OFTEN является важной функцией непрерывной интеграции. Для полной разбивки см. Эта статья