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

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

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

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

ИЗМЕНИТЬ

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

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

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

A Система непрерывной интеграции - это инструмент (например, Cruise Control), который отслеживает репозиторий исходного кода один раз в N минут.

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

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

Ответ 3

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

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

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

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

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