Скажем, есть команда из десяти гибких разработчиков. Каждый день они выбирают задачу с доски, вносят в нее несколько изменений, пока (к концу дня) не выполнят задачу. Все разработчики регистрируются напрямую в транке (в стиле Google, каждый коммит является кандидатом на релиз, с использованием переключателей функций и т. Д.).
Если они использовали централизованный CVS, такой как SVN, каждый раз, когда один из них фиксирует коммит, сервер сборки будет интегрировать и тестировать свои изменения в сравнении с работой других девяти разработчиков. Сервер сборки будет работать непрерывно весь день.
Но если бы они использовали DCVS, такой как git, разработчик может подождать, пока они завершат задачу, прежде чем отправить все свои локальные коммиты вместе в центральный репозиторий. Их изменения не будут интегрированы до конца дня.
В этом сценарии команда SVN постоянно интегрируется и обнаруживает проблемы интеграции намного быстрее, чем команда git.
Означает ли это, что DVCS менее подходят для непрерывных команд, чем старые централизованные инструменты? Как вы, ребята, справляетесь с этой проблемой отсрочки?
Ответы:
Отказ от ответственности: я работаю на Atlassian
DVCS не препятствует непрерывной интеграции до тех пор, пока разработчик регулярно отправляет удаленно в свою собственную ветвь, а сервер CI настроен так, чтобы он строил известные активные ветки.
Традиционно есть две проблемы с DVCS и CI:
В Bamboo мы представили возможность для сервера сборки обнаруживать новые ветви по мере их создания разработчиками и автоматически настраивать сборки для ветви на основе конфигурации сборки для master (поэтому, если вы измените конфигурацию сборки master, она также изменит конфигурацию веток чтобы отразить изменения).
У нас также есть функция под названием «Стратегии слияния», которую можно использовать для обновления ветви с изменениями от master до запуска сборки ветки или для автоматического перевода изменений в успешной ветке сборки на master, гарантируя, что изменения между ветвями тестируются вместе как можно скорее. ,
В любом случае, если вы заинтересованы в получении дополнительной информации, см. Мой пост в блоге "Как сделать функциональные ветви эффективными с помощью непрерывной интеграции"
источник
Моя маленькая команда перешла на DVCS год или два назад, а остальная часть моей компании последовала примеру пару месяцев назад. По моему опыту:
источник
Недавно я наблюдал около 19 проектов, в которых использовалась Mercurial over SubVersion (я был фанатом Subversion ): разработчики стали действительно индивидуалистами, работая над собственной веткой и интегрируясь только через несколько дней или недель. Это вызвало серьезные проблемы и проблемы интеграции.
Другая проблема, с которой мы столкнулись, связана с сервером непрерывной интеграции. Мы были уведомлены о проблемах (например, провал теста), только когда была произведена синхронизация коммитов с сервером.
Похоже, что Мартин Фаулер написал об этом на своем сайте.
Тем не менее, некоторые из проектов, о которых я упоминал, делали синхронизацию, по крайней мере, один раз в день, уменьшая проблемы. Поэтому, чтобы ответить на ваш вопрос, я думаю, что DVCS может препятствовать постоянной интеграции и усиливать индивидуализм. Однако DVCS не является непосредственной причиной.
Разработчик все еще отвечает за VCS, который они используют.
источник
Идея, на которой вы основываете свои рассуждения, очень шаткая, мягко говоря. Это вопрос команды / управления / процесса, что разработчик может подождать, пока они не выполнят задачу .
Выполнение этого так или иначе, «ожидание» или «спешка», общий ствол или изолированная ветвь, называется стратегией ветвления , и если вы изучите информацию, доступную в Интернете , вы обнаружите, что выбор конкретной стратегии в основном не имеет ничего общего с VCS централизован или распределен.
Скажем, для распределенных VCS, таких как Mercurial, вы можете легко найти сильную рекомендацию для частых слияний :
Изучая рекомендации, подобные приведенным выше, можно легко обнаружить, что они обращаются к соображениям, не имеющим никакого отношения к распространению Mercurial.
Теперь давайте посмотрим на ситуацию на стороне централизованного VSC, Subversion. Изучая онлайн информацию, можно найти среди популярных стратегий так называемые стабильные магистрали и нестабильные магистрали, каждая из которых оказывает противоположное влияние на частоту слияний. Видите ли, люди выбирают тот или иной способ действий, даже не обращая внимания на централизацию VCS.
Учитывая вышесказанное, это выглядит как правильный ответ на вопрос о том, препятствуют ли DVCS непрерывной интеграции? будет му .
Распространение VCS или нет, не оказывает существенного влияния на это.
источник
Мой опыт совершенно противоположен : команды, использующие svn, не будут продвигаться целыми днями, потому что код, над которым они работают, может заставить транк не компилироваться для всех остальных, не тратя время на ручное объединение. Затем, ближе к концу спринта, все совершали свои действия, происходило слияние безумия, вещи переписывались и терялись, и их приходилось восстанавливать. Система CI станет КРАСНОЙ, и начнется указание пальцем.
Никогда не было этой проблемы с Git / Gitorious.
Git позволяет вам извлекать и объединять изменения других людей по вашему усмотрению не потому, что кто-то еще что-то проверил, и вы хотите проверить, но у вас есть 20 минут на ручное объединение.
Git также позволяет вам извлекать коммиты всех остальных, объединять ваш код, а затем передавать рабочую версию всем остальным, чтобы им не приходилось угадывать, что им нужно объединять, основываясь на том, что вы изменили.
Наличие чего-то вроде Gitorious в качестве посредника для проверки кода через запросы на слияние делает управление многими ветками и многими участниками очень безболезненным.
Настроить Jenkins / Hudson для отслеживания всех активных веток в репозитории Git также очень просто. Мы получили больше поддержки с CI и более частые отзывы о состоянии репозиториев, когда мы перешли на Git из SVN.
источник
Сборка серверов стоит дешево. Просто пусть ваш CI-сервер подберет все ветки, о которых вы знаете.
У Дженкинса есть поддержка, чтобы проверить несколько репозиториев git и получить «последние» из любого из них в одной работе. Я уверен, что есть аналогичные решения с другими инструментами.
источник
head
но помогает коллеге или требуется, чтобы коллега мог помочь вам? Вы можете создать разницу и отправить это по электронной почте своему коллеге, но почему-то это не так.Этот старый вопрос был помечен как дубликат нового, и, поскольку во многих ответах упоминаются устаревшие идеи, я решил опубликовать обновленный.
Одна вещь, которая, по-видимому, не очень часто встречалась пять лет назад, это запуск тестов 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
). Обычно я делаю это много раз в день, работая таким образом.Итак, у вас есть: небольшие коммиты, частая интеграция и прослеживаемая история того, какие коммиты принадлежали какой функции. Правильно используемые ветки являются ключом ко всему, что стоит делать в Git, поэтому избегать их - большая ошибка.
источник
Есть замечательные технические решения, такие как @jdunay, но для нас это проблема людей - точно так же, как создание среды, в которой люди часто совершают svn, - это проблема людей.
Для нас работает: (замените 'master' на текущую активную ветку dev)
Осведомленность о вещах, которые вызывают ад слияния, такие как определенные рефакторинги, и смягчение этого посредством общения. Например:
источник