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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Люди, использующие централизованную VCS, все еще имеют тенденцию удерживать коммиты, когда они делают большой проект. Это не проблема, уникальная для DVCS. У них будут наборы изменений, которые ждут несколько дней, прежде чем делать коммит. Большая разница в том, что если они совершают ошибку в какой-то момент в течение этого времени или если компьютер выходит из строя, это требует значительно больших усилий для ее исправления.
• Мы используем рабочий процесс фиксации, где каждый разработчик работает в своей собственной именованной ветви, и только тот, кто просматривал их код, может объединить свои изменения в голове. Это снижает вероятность коммита, вызывающего проблемы, поэтому люди действительно обращают внимание, когда сервер сборки выдает сообщение об ошибке. Это также означает, что другие разработчики могут продолжать работать над своими собственными ветками, пока голова не будет исправлена.
• В DVCS люди, как правило, тратят больше времени на программирование, прежде чем сливать свой код с головой. Так что это имеет тенденцию вносить небольшое отставание в непрерывность сборки. Но разница не настолько существенна, чтобы противостоять преимуществам DVCS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Частые слияния / ребазы от мастера
2. Достаточно частые толчки, чтобы освоить

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

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