Каков рабочий процесс Непрерывной Интеграции С Гудзоном?
Я отнесен в Гудзон сегодня.
Я услышал о непрерывной интеграции прежде, но я понятия не имею, какого черта ci-сервер.
Гудзон действительно легко установить в Ubuntu и за несколько минут, мне удалось настроить экземпляр его.
Но я не вполне понимаю рабочий процесс ci-сервера, или как я, как предполагается, использую его?
Скажите мне, если у Вас есть опыт о ci, заранее спасибо.
Править:
Я в настоящее время использую Подвижный в качестве своего SCM и интересно, что правильный путь состоит в том, чтобы использовать его с Гудзоном.
Я установил Подвижный Плагин Гудзона, и я создаю новое задание с локальным репозиторием. Когда я фиксирую в репозитории Hudson задание создается с последней версией моего исходного кода.
Если то, что я использовал, является удаленным репозиторием, как что рабочий процесс?
Это - что-то как следующее?
- Настроенный a
Hudsonзадание с репозиторием - Разработчик делает локальный клон репозитория
- Фиксация разработчика и изменения нажатия
- Удаленный репозиторий обновляет с поступлением changeset
- Выполненный a
Hudsonсборка
Может быть что-то, что я неправильно понял вообще, помогите мне указать на это.
2 ответа
Непрерывная интеграция - это процесс «интеграции программного обеспечения» непрерывно, то есть как можно чаще (в конечном счете, после каждого набора изменений), чтобы избежать любой интеграции большого взрыва и всех последующих проблем путем получения немедленной обратной связи.
Чтобы реализовать непрерывную интеграцию, вам сначала необходимо автоматизировать сборку вашего программного обеспечения (где сборка, конечно, означает компиляцию исходных текстов, их упаковку, но также и компиляцию тестов, запуск тестов, выполнение проверок качества и т. Д., Все, что поможет получить отзывы о работоспособности вашего кода). Затем вам нужно запустить сборку последней версии источников для определенного события (изменение в репозитории, временное событие), чтобы сгенерировать отчеты и отправить уведомления в случае сбоя (по почте, в твиттере и т. Д.).
И это как раз ответственность механизма CI: предлагать механизмы запуска, иметь возможность получать последнюю версию исходных текстов, запускать сборку, генерировать и публиковать отчеты, отправлять уведомления. Движки CI это реализуют.
И поскольку запуск сборки требует интенсивного использования ЦП и диска, механизмы CI обычно работают на выделенной машине (или даже на ферме машин, если вы хотите собрать много проектов).
Теперь вернемся к вашему вопросу. После запуска Hudson настройте его ( Управление Hudson> Настроить систему ): настройте JDK, инструменты сборки и т. Д. Затем настройте Hudson Job и выполните следующие действия: настройка расположение исходного репозитория, инструмент сборки, триггер, канал уведомлений, и все готово (вы можете делать более сложные вещи, но это только начало).
Для получения дополнительных сведений о настройке см.
- Официальное руководство Используйте Hudson для получения дополнительных сведений. << НАЧНИТЕ ЗДЕСЬ
- Непрерывная интеграция с Hudson - Учебное пособие .
- Выявление дефектов на раннем этапе с помощью непрерывной интеграции .
Обзор непрерывной интеграции Мартина Фаулера является одной из канонических ссылок. На мой взгляд, использование автоматизации для проверки работоспособности вашей кодовой базы - одна из самых полезных вещей, которые вы можете настроить.
Обновление Извините, что раньше у меня не было времени подробно рассказать о своем ответе.@Pascal_Thivent прав в том, что для эффективного использования CI вам необходимо иметь возможность автоматизировать ваши сборки, тесты и т. Д. CI на самом деле является хорошей функцией форсирования для этого. Для меня это один из тех маленьких предупреждений, если я начинаю думать, что было бы слишком больно размещать сборку в Hudson. Значит, что-то не так.
Что мне нравится в Hudson, так это то, что он достаточно гибкий, чтобы приспособиться к различным рабочим процессам. Мы используем его как для сборок / модульных тестов, так и для релизов. И это избавляет от необходимости беспокоиться о том, что определенные процедуры выпуска работают только в среде одного человека.
Что мне не нравится в Hudson, так это то, что он иногда нестабилен, когда новые сборки ломают плагины. У меня было несколько обновлений (2 из 10 или около того), которые пошли плохо из-за несовместимости. Сейчас я делаю две вещи:
- Я никогда не обновляю сервер Hudson моей команды до последней и лучшей сразу. Обычно я обновляюсь только тогда, когда появляются важные новые функции или исправления ошибок.
- Теперь у меня есть базовый экземпляр Hudson, настроенный со всеми моими плагинами на виртуальной машине с некоторыми фиктивными сборками, которые я запускаю для тестирования любых новых обновлений, прежде чем делать это на общедоступном сервере.