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

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

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

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

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

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

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

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

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

Hope Вы находите ссылки интересными.

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

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

Как добавленная премия, там немного находится на одном уровне интеграционного тестирования, которое происходит автоматически.

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

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

пикосекунда, Где Вы получали те ссылки подхода? - не чувствует, что те графики представляют все опции

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

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

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

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

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

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

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

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

Сказав это...

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

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

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

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

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

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