Непрерывная интеграция с распределенным контролем исходного кода
Я думаю, что что-то неправильно понимаю, но не могу найти что именно. Я погуглил, но не понял. Существует два популярных метода - непрерывная интеграция и управление распределенным исходным кодом. Люди как-то их объединяют, но я не понимаю как.
AFAIK, непрерывная интеграция означает фиксацию в центральном репозитории (push), как только вы протестировали свой код локально. В то же время распределенные системы очень любят, среди прочего, потому что вы можете фиксировать, фиксировать и фиксировать локально, играть с кодом и передавать его остальным только тогда, когда вы уверены и достаточно довольны им. Так что, хотя это и не принуждает, но и побуждает не торопиться с толчком. Мне кажется, что классического для CI push каждые несколько часов не будет.
Так как и когда вы связываете эти две вещи вместе? Или я не прав в том, что сказал?
РЕДАКТИРОВАТЬ
Я прочитал первые три ответа. Спасибо за ответ. Я все еще в замешательстве, но теперь я могу сформулировать вопрос более точно.
В распределенных системах желания частых коммитов не так велики, как в централизованных. Так есть ли какие-либо рекомендации о том, как часто публиковать в распределенных системах для соответствия CI? Это все еще несколько раз в день или есть другая версия этого правила?
3 ответа
Распределенное управление источниками и непрерывная интеграция не являются взаимоисключающими понятиями. На самом деле они играют очень хорошо вместе.
Несмотря на то, что DVCS по своей природе распределены, у вас все равно будет центральный репозиторий, представляющий традиционный "ствол", обнаруженный в централизованных системах версий. Вы не должны изменять свою модель разработки с точки зрения того, когда и какие изменения вы "публикуете" в своем центральном хранилище. Поскольку DVCS не заставляет вас настаивать на своих изменениях, вы должны быть очень дисциплинированными в этом отношении.
С другой стороны, DVCS позволяет разработчикам делать меньшие, инкрементные коммиты в своих частных ветвях. Этим изменениям не только легче следовать, но и их легче объединить в конце. Наличие локальных коммитов особенно полезно при добавлении функции или экспериментальных изменений. Или когда вам нужно прервать работу над функцией A, чтобы исправить очень важную ошибку B.
Индивидуальный разработчик решает, что будет опубликовано и когда. Как всегда, с дополнительной силой приходит дополнительная ответственность.
Вы должны публиковать / публиковать изменения всякий раз, когда они готовы. Например я хочу переименовать класс. Это коснется 50+ файлов, хотя всего несколько строк. Я делаю переименование с помощью инструмента рефакторинга.
В централизованной системе мне теперь нужно будет решить, стоит ли это делать самому по себе, или это часть большой работы, над которой я сейчас работаю. Исходя из своего опыта, люди обычно выбирают второй вариант, потому что вы не уверены, хотите ли вы, чтобы это было частью постоянной истории.
В распределенной системе я могу зафиксировать изменение локально, у меня есть четкая история, разделяющая механические (рефакторинг) и функциональные изменения кода. На данный момент я ни на кого не влияю. Я мог бы легко пересмотреть это решение позже, прежде чем окончательно отречься от своих изменений. Это будет чистый коммит сам по себе.
Проблема в этом примере заключается в следующей ситуации: представьте, что я переименую этот класс в моей локальной ветке или в моем "отложенном коммите". Тем временем кто-то передает новый код транку, который использует класс, который я только что переименовал. Это будет хлопот, чтобы объединить мое переименование.
Конечно, вы могли только что опубликовать это изменение в тот момент, когда вы это сделали. В обеих системах. Ответственность все та же. Но так как DVCS поощряет вас иметь меньшие, постепенные коммиты, объединение будет легче. Обе системы могли бы предоставить вам одну и ту же "стратегию выхода" из этой ситуации, если вы опубликовали свои изменения заранее.
Система непрерывной интеграции - это инструмент (как, например, Cruise Control), который контролирует ваш репозиторий исходного кода один раз каждые N минут.
Каждый раз, когда что-то меняется (кто-то фиксирует код), CI включается, запускает все тесты и затем отправляет вывод (с ошибками или нет) куда-то, например, по электронной почте или на экран.
CI никак не зависит от типа VCS, который вы используете, независимо от того, распространяется он или нет.
В этом есть ряд элементов, некоторые из которых связаны с программным обеспечением, а некоторые - с процессами.
Системы контроля версий - это всего лишь контроль версий. Возможность отката, ветвления и слияния и т. Д., Независимо от того, являются ли они централизованными или распределенными и имеют ли они верхнюю и нижнюю стороны. VCS как таковые не помогают вам лучше кодировать или лучше выполнять проекты, они облегчают процесс разработки в командах, если и когда команды работают правильно. Другими словами, вы можете облажаться так же по-королевски, используя SVN или Mercurial, как без него.
Когда CI приходит, это не код в течение нескольких дней, а затем фиксация, затем сборка проекта и тестирование, кодер коммит чаще, 1/2 дня 1 день (макс.) И проект создается и тестируется (не выпускается для использования). Это означает, что любые ошибки обнаруживаются раньше и могут быть легко исправлены, поскольку было зафиксировано меньше кода и память программистов стала более свежей.
CI может быть сделан вручную, или он может быть написан с помощью сценариев, написание сценариев CLI сделает это, или может быть настроен один из множества программных инструментов CI, которые будут интегрированы с CVS, чтобы выполнять этот процесс автоматически или полуавтоматически, чтобы уменьшить управление и умение делать ошибки.
Преимущество использования существующих инструментов, Mercurial + Hudson, или SVN и Cruise Control, заключается в том, что вы поддерживаете мудрость и опыт людей, которые, возможно, в какой-то момент облажались по-королевски, но усвоили урок. Чего вы не можете сделать, так это достать его из коробки и использовать его и ожидать, что он будет работать без добавления в процесс вашего собственного процесса для вашего собственного проекта.