Являются ли DVCS, такие как Git, неподходящими для команд, использующих непрерывную интеграцию?

Question

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

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

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

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

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

Answer 1

На самом деле DVCS значительно упростила непрерывную интеграцию.

С центральным VCS каждый разработчик имеет права на коммит непосредственно в транке, и поэтому он может коммитить глючный код. CI обнаружит это по факту. Так что возможно сломать багажник даже с КИ.

С другой стороны, основные операции в мире DVCS - это ветвление и слияние. Поскольку слияние является явным и представляет собой отдельный процесс по сравнению с фиксацией в транке, всегда можно проверить результат слияния до того, как попадет в транк. У меня нет опыта работы с Git, но разработчики Bazaar VCS успешно использовали эту технику как минимум 3,5 года с помощью инструмента PQM.

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

Инструменты непрерывной интеграции, такие как Hudson, поддерживают DVCS, поэтому я подозреваю, что это возможно для согласования непрерывной интеграции с распределенным контролем версий.

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

---

Добавлено 07.08.2009:

См., Например, Весенняя очистка непрерывной интеграции публикация в блоге GitHub.

Answer 5

Две идеи, которые я нашел, помогают объяснить это:

• DVCS отделяет коммиты от слияний.
• CI работает с выбранным вами хранилищем.

Итак, суть дела в том, как слияния в репозитории, с которыми вы хотите запустить инструмент CI. При запуске вы можете выбрать только один репозиторий.