Лучшая стратегия ветвления при непрерывной интеграции?

Какую стратегию ветвления лучше всего использовать, если вы хотите осуществить непрерывную интеграцию?

1. Разветвление выпуска: развивайте в стволе, сохраняйте ветку для каждого выпуска.
2. Ветвление функций: разрабатывайте каждую функцию в отдельной ветке, объединяйте только после стабильной работы.

Имеет ли смысл использовать обе эти стратегии вместе? Например, вы переходите для каждого выпуска, но вы также переходите для крупных функций? Лучше ли сочетается одна из этих стратегий с непрерывной интеграцией? Будет ли иметь смысл использование непрерывной интеграции при использовании нестабильной магистрали?

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

• Я помню, как Марк Шаттлворт предложил модель сохранения основной ветви в первозданном виде, выходя за рамки обычного CI. Я написал об этом здесь .
• Так как я знаком с круиз - контролем, я также писал о филиалах группы и CI здесь . Это пошаговое руководство, объясняющее, как это сделать с помощью Plastic SCM .
• Наконец, я обнаружил, что некоторые темы о CI (и, возможно, разговоры о ветвлении) в книге Дюваля по CI тоже очень интересны. .

Надеюсь, ссылки будут вам интересны.

Ответ зависит от размера вашей команды и качества вашей системы управления версиями, а также от способности правильно объединять сложные наборы изменений. Например, при полном управлении исходным кодом ветви, таком как слияние CVS или SVN, может быть сложно, и вам может быть лучше с первой моделью, в то время как при использовании более сложной системы, такой как IBM ClearCase, и с большим размером команды вам может быть лучше со второй. модель или их комбинация.

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

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

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

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

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

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

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

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

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

http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitToTheMainlineEveryDay

РЕДАКТИРОВАТЬ

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

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

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

ДРУГОЙ РЕДАКТИРОВАНИЕ

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

http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/

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

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

Так что для меня использование обоих механизмов - очень хорошая стратегия.

Интересная ссылка из Книги СВН .

Недавно мне понравилась эта модель при использовании git. Хотя ваш вопрос помечен как «svn», вы все равно можете его использовать.

Непрерывная интеграция может в некоторой степени происходить в ветке «разработка» (или как вы ее называете) в этой модели, хотя наличие длительных функциональных веток для будущих выпусков не сделает ее настолько жесткой, чтобы учитывать каждое изменение, происходящее где-то в коде. Остается вопрос, действительно ли вы этого хотите. Мартин Фаулер знает.

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

Было сказано, что ...

• нет причин, по которым CI нельзя использовать в обоих описанных вами подходах
• эти подходы хорошо работают в сочетании
• ни один из двух не работает «лучше», чем другой
• CI имеет смысл при нестабильном стволе

На все это был дан ответ в четвертом вопросе на странице, с которой вы взяли диаграммы: http://blogs.collab.net/subversion/2007/11/branching-strat/

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

Чтобы лучше познакомиться с основной моделью, прочитайте это: https://web.archive.org/web/20120304070315/http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

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

http://www.infoq.com/articles/agile-version-control

Когда мы начинали нашу команду, мы унаследовали стратегию на основе релизов от поставщика, который изначально разработал систему, за которую мы собирались отвечать. Это работало до тех пор, пока наши клиенты не потребовали, чтобы некоторые разработанные функции не были включены в релиз (например, ~ 250 тыс. Строк кода, ~ 2500 файлов, Scrum с XP SDLC).

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

Последний «гвоздь в крышку гроба» чистых SC-стратегий пришел, когда мы решили, что у нас должен быть 1. стабильный ствол и 2. рабочий должен содержать ST, UAT и регрессивно протестированные БИНАРИИ (а не только источник - подумайте CC).

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

Итак, у нас есть багажник. В каждом спринте мы разветвляем ветвь спринта (для не гибких людей спринт - это просто ограниченная по времени разработка с переменным выходом в зависимости от сложности). Из ветки спринта мы создаем ветви функций, и в них начинается параллельная разработка. После того, как функции завершены, система протестирована и мы получаем намерение развернуть их, они объединяются в ветвь спринта - некоторые из них могут перемещаться по нескольким спринтам, обычно более сложные. Когда спринт подходит к концу и все функции завершены ... мы «переименовываем» ветвь спринта в «регрессию» (это позволяет CruiseControl выбрать ее без какой-либо реконфигурации), а затем начинается регрессионное / интеграционное тестирование на cc-built. EAR. Когда все это будет сделано, оно будет запущено в производство.

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

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

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

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

ps Где вы взяли эти ссылки на подходы? - не кажется, что эти графики представляют все варианты

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

Дэйв Фарли , автор книги « Непрерывная доставка» , назвал разработку на основе магистрали (TBD) краеугольным камнем непрерывной интеграции (CI) и непрерывной доставки (CD). Он говорит:

Любая форма ветвления противоположна непрерывной интеграции.

Он также говорит:

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

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

Я работаю над Trunk, «мастером» в репозиториях GIT. Я обязуюсь выполнить локальное управление и сразу же, когда я подключен к сети, отправляю в центральное главное репозиторий, где работает CI. Это оно!

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

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

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

• Если вы используете Subversion, придерживайтесь варианта 1 и выпустите из веток.
• Если вы используете GIT, вам подойдет вариант 2.