Непрерывная интеграция с распределенным контролем исходного кода

Question

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

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

Итак, как и когда вы связываете эти две вещи вместе? Или я ошибаюсь в том, что я сказал?

EDIT

Я прочитал первые три ответа. Спасибо за ответ. Я все еще смущен, но теперь я могу сформулировать вопрос более точным.

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

Answer 1

Управление распределенным источником и непрерывная интеграция не являются взаимоисключающими понятиями. На самом деле они очень хорошо играют вместе.

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

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

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

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

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

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

Проблема в этом примере связана со следующей ситуацией: представьте, что я переименую этот класс в свою локальную ветвь или мое «отложенное совершение». Тем временем кто-то компилирует новый код в багажник, который использует класс, который я только что переименовал. Это будет хлопот, чтобы объединить мое переименование.

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

Answer 2

Каждый раз, когда что-то меняется (кто-то совершает код), CI переходит вперёд, запускает все тесты и затем отправляет выходные данные (отказы или нет), например, электронную почту или экран.

CI никоим образом не зависит от типа используемого VCS, независимо от того, распространяется оно или нет.

Answer 3

Для этого существует ряд элементов, некоторые из которых связаны с программным обеспечением, некоторые связаны с процессом.

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

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

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

Преимущество использования существующих инструментов Mercurial + Hudson, или SVN и Cruise Control заключается в том, что вы поддерживаете мудрость и опыт людей, которые, возможно, в какой-то момент, возможно, прищурились, но извлекли урок. То, что вы не можете сделать, это получить его из коробки и использовать его и ожидать, что он будет работать без добавления собственного процесса для вашего собственного проекта в микс.