DVCSs препятствуют непрерывной интеграции?

34

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

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

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

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

Означает ли это, что DVCS менее подходят для непрерывных команд, чем старые централизованные инструменты? Как вы, ребята, справляетесь с этой проблемой отсрочки?

Ричард Дингуолл
источник
15
Будут ли люди совершать хотя бы один раз перед выполнением задачи при использовании SVN? И будут ли люди толкаться только один раз в день при использовании DVCS? Ваше рассуждение предполагает, что ни один из них не соответствует действительности, но мое впечатление указывает на обратное.
3
Очень хороший вопрос
Майкл Браун
1
@delnan: предположим, что обе команды совершают коммиты несколько раз в день, но парни из git только объединяют эти коммиты, когда задача выполнена.
Ричард Дингуолл
2
Я думаю, что вы смотрите не с того конца канала, у вас возникают проблемы, не если вы не выполняете работу до конца, а если вы не выполняете регулярные операции во время разработки
jk.
2
Я видел обратное: разработчики, использующие централизованную систему управления исходным кодом, такую ​​как TFS, выполняют коммиты редко, потому что их код влияет на всех, когда они это делают. В конечном итоге они временно сохраняют свою работу в наборе шельфов монстров, а когда они заканчивают, все это происходит за один коммит монстров.
Kyralessa

Ответы:

26

Отказ от ответственности: я работаю на Atlassian

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

Традиционно есть две проблемы с DVCS и CI:

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

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

У нас также есть функция под названием «Стратегии слияния», которую можно использовать для обновления ветви с изменениями от master до запуска сборки ветки или для автоматического перевода изменений в успешной ветке сборки на master, гарантируя, что изменения между ветвями тестируются вместе как можно скорее. ,

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

jdumay
источник
14

Моя маленькая команда перешла на DVCS год или два назад, а остальная часть моей компании последовала примеру пару месяцев назад. По моему опыту:

  • Люди, использующие централизованную VCS, все еще имеют тенденцию удерживать коммиты, когда они делают большой проект. Это не проблема, уникальная для DVCS. У них будут наборы изменений, которые ждут несколько дней, прежде чем делать коммит. Большая разница в том, что если они совершают ошибку в какой-то момент в течение этого времени или если компьютер выходит из строя, это требует значительно больших усилий для ее исправления.
  • Мы используем рабочий процесс фиксации, где каждый разработчик работает в своей собственной именованной ветви, и только тот, кто просматривал их код, может объединить свои изменения в голове. Это снижает вероятность коммита, вызывающего проблемы, поэтому люди действительно обращают внимание, когда сервер сборки выдает сообщение об ошибке. Это также означает, что другие разработчики могут продолжать работать над своими собственными ветками, пока голова не будет исправлена.
  • В DVCS люди, как правило, тратят больше времени на программирование, прежде чем сливать свой код с головой. Так что это имеет тенденцию вносить небольшое отставание в непрерывность сборки. Но разница не настолько существенна, чтобы противостоять преимуществам DVCS.
StriplingWarrior
источник
Сервер сборки создает все именованные ветви, поэтому у каждого коммиттера есть своя собственная работа сервера сборки?
Разве рецензент кода не станет серьезным узким местом в этом сценарии?
Андрес Ф.
@ ThorbjørnRavnAndersen: Нет, сервер сборки создает только ветку «head» или «default», а ветки выпуска. Таким образом, каждый пользователь может зафиксировать свою собственную именованную ветку, не боясь нарушить сборку. Мы могли бы создать сервер сборки для создания ветвей каждого, но в некоторых случаях я хочу совершить некоторую работу, которую я проделал, прекрасно зная, что она переводит мою собственную ветку в непригодное для использования состояние. Я проверю, стабильна ли моя ветка, прежде чем я сделаю обзор кода и сливаюсь. Меня волнует только то, что основные ветви, которые используют все остальные, стабильны.
StriplingWarrior
@ AndresF .: Нет, это не стало для нас серьезным узким местом. Во-первых, у нас есть несколько человек, которые могут выполнять рецензирование кода, поэтому каждый разработчик обычно может найти хотя бы одного рецензента, который доступен для рецензирования в любой момент времени. Кроме того, отчасти красота DVCS заключается в том, что даже если вы не можете сразу слиться, вы можете начать работать над чем-то другим, а другие разработчики могут объединить ваши изменения в свои ветви, если они зависят от ваших изменений в своей работе. Как только ваш код проверен, существует конкретный узел ревизий, в который может объединить рецензент.
StriplingWarrior
13

Недавно я наблюдал около 19 проектов, в которых использовалась Mercurial over SubVersion (я был фанатом Subversion ): разработчики стали действительно индивидуалистами, работая над собственной веткой и интегрируясь только через несколько дней или недель. Это вызвало серьезные проблемы и проблемы интеграции.

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

Похоже, что Мартин Фаулер написал об этом на своем сайте.

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

Разработчик все еще отвечает за VCS, который они используют.

Сообщество
источник
Делали ли указанные проекты акцент на общей цели, или разработчикам приходилось работать над конкретными, оторванными целями?
Мы не можем обобщать 19 проектов. Но когда мы столкнулись с проблемами интеграции, это также потому, что некоторые принципы, такие как разделение интересов, не были соблюдены. Что я говорю, так это то, что да, DVCS, кажется, поощряет индивидуализм и уменьшает преимущества непрерывной интеграции, но, если разработчики хорошо подготовлены, можно уменьшить или устранить проблему.
В этом случае я бы посоветовал вам также осуществлять непрерывную доставку или, по крайней мере, частую доставку клиентам, поэтому крайний срок, когда ОБЯЗАТЕЛЬНО должно произойти слияние, намного короче. Вы делали это в этих проектах?
Конечно, мы используем Scrum
1
Я искал ваше определение непрерывной доставки (все еще не могу найти что-то приличное, я буду признателен, если бы вы могли дать мне несколько ссылок), и нашел это: непрерывныйdelivery.com
10

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

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

Скажем, для распределенных VCS, таких как Mercurial, вы можете легко найти сильную рекомендацию для частых слияний :

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

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

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

  • Я видел слияния с задержкой, которые происходят (даже поощряемые неэффективным управлением) с централизованным VCS, а также частые слияния, выполняемые с DVCS, когда команда / руководство просто считали, что это правильный путь. Я видел, что никого не волнует, распространяется ли VCS или централизовано при принятии решения, так или иначе.

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

Распространение VCS или нет, не оказывает существенного влияния на это.

комар
источник
1
+1 Я согласен с вами, что управление - это ключ к решению проблемы. Однако мы должны признать, что в DVCS есть что-то, что препятствует непрерывной интеграции. Фактически, одна из ключевых особенностей DCVS поощряет такое поведение.
1
@ Pierre303 возможно - я тоже так чувствую, но это в значительной степени теория. Как я уже писал, я видел, как команда как сумасшедшая интеграция с DVCS и, с другой стороны, самый «изоляционистский» проект, в котором я когда-либо работал (и это был кошмар), был с централизованным VCS. Так много для чувств, так много для теории ...
Гнат
Я признаю, что это только эмпирическое наблюдение, но по большому количеству проектов, и, вероятно, это связано с огромным смещением «навыков».
10

Мой опыт совершенно противоположен : команды, использующие svn, не будут продвигаться целыми днями, потому что код, над которым они работают, может заставить транк не компилироваться для всех остальных, не тратя время на ручное объединение. Затем, ближе к концу спринта, все совершали свои действия, происходило слияние безумия, вещи переписывались и терялись, и их приходилось восстанавливать. Система CI станет КРАСНОЙ, и начнется указание пальцем.

Никогда не было этой проблемы с Git / Gitorious.

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

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

Наличие чего-то вроде Gitorious в качестве посредника для проверки кода через запросы на слияние делает управление многими ветками и многими участниками очень безболезненным.

Настроить Jenkins / Hudson для отслеживания всех активных веток в репозитории Git также очень просто. Мы получили больше поддержки с CI и более частые отзывы о состоянии репозиториев, когда мы перешли на Git из SVN.


источник
почему они передают напрямую в ствол? Я думаю, что это была твоя проблема.
gbjbaanb
1
@gbjbaanb, потому что это традиционный идиоматический способ работы CVS, потому что это традиционная идиома централизованного репо. Пользователи SVN обычно являются бывшими пользователями CVS, и ветвление и слияние в SVN лишь незначительно лучше, чем в CVS; который был за пределами болезненного / почти невозможно получить правильное. Это 99% рабочих процессов в 99% всех магазинов SVN из-за инструментов и группового мышления.
@JarrodRoberson: глупость. Мои старые пользователи SVN были беженцами из VSS :) Слияние в SVN не так плохо, как вы думаете. В этом случае он жалуется, что его пользователи будут нарушать сборку, проверяя поврежденный код непосредственно в транке - и затем, если честно, необходимость слияния вашего кода с кодом вашего коллеги не является дополнительной вещью, если вы все работаете непосредственно над та же ветка.
gbjbaanb
4

Сборка серверов стоит дешево. Просто пусть ваш CI-сервер подберет все ветки, о которых вы знаете.

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

ptyx
источник
И что произойдет, если вы захотите совершить что-то, что нарушает, headно помогает коллеге или требуется, чтобы коллега мог помочь вам? Вы можете создать разницу и отправить это по электронной почте своему коллеге, но почему-то это не так.
Арджан
1
Командная / тематическая ветка? Или прямое извлечение из вашего коллегного хранилища? Если более чем один человек работает над чем-то, что сломало бы голову, но все же требует временной / многоэтапной фиксации, он все равно заслуживает своей ветви функций / работы. Слияние с головой, когда оно будет готово.
ptyx
Коллективная ветвь функциональной ветки не будет работать, если ваш инструмент CI подберет все известные вам ветки. И если ваш инструмент CI также обрабатывает несколько репозиториев, вы все равно не хотите включать репозитории разработчиков, просто потому что они, возможно, не были полностью протестированы.
Арджан
1
Сервер CI не будет автоматически знать о частной ветке, пока ему не сообщат об этом. Частным лицам выбирать, хотят ли они свои ветви на КИ или нет. (
Чудесного
Поэтому CI не должен собирать все ветки, о которых вы знаете, а только те, которые вам нужны в CI. Для меня это разница. Тем не менее, я думаю, я понимаю, что вы пытаетесь сказать, так что +1
Арджан
4

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

Одна вещь, которая, по-видимому, не очень часто встречалась пять лет назад, это запуск тестов CI в ветвях с запросами на извлечение перед их объединением в master. Я думаю, что это отражает изменяющуюся позицию, что хотя слияние часто желательно, делиться каждым изменением со всеми , как только вы это сделаете , не оптимально.

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

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

Однако, если кто-то не может дождаться, когда наши изменения сливаются с master, потому что их изменение зависит от наших, они могут слить нашу ветку dev локально и продолжить свою работу. Это то, что упускают многие люди, привыкшие к CVCS. В CVCS единственный способ поделиться своими изменениями - это объединить их с центральным репо, и поэтому объединение часто является более важным. С DVCS у вас есть другие варианты.

Карл Билефельдт
источник
3

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

Майкл Браун
источник
2

Когда моя команда перешла на Git, мы явно изложили наш процесс так, что push-код должен обрабатываться точно так же, как и коммит в более старой VCS, а локальные коммиты могли выполняться так часто / нечасто, как выбрал каждый человек. При этом для системы CI нет разницы, используем ли мы DVCS или централизованную VCS.

Дэн Лайонс
источник
1

Ответ и да, и нет.

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

Я бы сказал, что это неотъемлемая конструктивная особенность DVCS, она не предназначена для постоянной доставки ваших изменений на центральный сервер - если бы это было так, вы могли бы вместо этого использовать CVCS. Таким образом, ответ заключается в том, чтобы обеспечить лучший рабочий процесс среди ваших разработчиков. Скажите им, чтобы толкать изменения каждую ночь. Simples!

(и если ваши пользователи SVN не совершают каждую ночь, скажите им - это точно такая же проблема).

gbjbaanb
источник
0

Git не мешает непрерывной интеграции. Ваш основанный на стволе рабочий процесс.

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

Я утверждаю, что рабочий процесс на основе соединительных линий в стиле Google является контрпродуктивным с VCS, такой как Git, где объединение легко. Вот что я бы посоветовал вместо этого:

  • Разбивайте функции настолько маленькими, что ни одна из них не займет больше, чем день или два, чтобы развиться.
  • Каждая функция разработана в частной ветке.
  • Разработчик часто интегрируется в частную ветку ( git fetch origin; git merge master). Обычно я делаю это много раз в день, работая таким образом.
  • Когда разработчик отправляет ветку для слияния и просмотра, CI-сервер выполняет автоматическую сборку. Слияние происходит только тогда, когда это проходит.

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

Марнен Лайбоу-Козер
источник
-1

Есть замечательные технические решения, такие как @jdunay, но для нас это проблема людей - точно так же, как создание среды, в которой люди часто совершают svn, - это проблема людей.

Для нас работает: (замените 'master' на текущую активную ветку dev)

  1. Частые слияния / ребазы от мастера
  2. Достаточно частые толчки, чтобы освоить
  3. Осведомленность о вещах, которые вызывают ад слияния, такие как определенные рефакторинги, и смягчение этого посредством общения. Например:

    • Убедитесь, что все толкают перед обедом
    • Выполните и нажмите рефакторинг во время обеда
    • Убедитесь, что все тянут после обеда
orip
источник