Как работает непрерывная интеграция с Hudson?

Question

Меня сегодня называют Гудзоном.

Я уже слышал о непрерывной интеграции, но я понятия не имею, что это за ci-сервер.

Hudson действительно легко установить в Ubuntu, и за несколько минут мне удалось настроить его экземпляр.

Но я не совсем понимаю рабочий процесс ci-сервера или как мне его использовать?

Скажите, пожалуйста, если у вас есть опыт работы с ci, заранее спасибо.

Edit:

В настоящее время я использую Mercurial в качестве SCM , и мне интересно, как правильно его использовать с Hudson .

Я установил Mercurial Plugin из Hudson , и я создаю новую работу с локальным хранилищем. Когда я фиксирую в репозитории, работа Hudson создается с последней версией моего исходного кода.

Если то, что я использовал, является удаленным репозиторием, каков рабочий процесс?

Это что-то вроде следующего?

1. Настройка Hudson задания с хранилищем
2. Разработчик делает локальный клон репозитория
3. Разработчик фиксирует и отправляет изменения
4. Обновление удаленного репозитория с входящей ревизией
5. Выполнить Hudson сборку

Может быть, я что-то неправильно понял, пожалуйста, помогите мне указать это.

Answer 1

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

Чтобы реализовать Continuous Integration, вам сначала нужно автоматизировать сборку вашего программного обеспечения (где сборка подразумевает, конечно, компиляцию источников, их упаковку, а также компиляцию тестов, запуск тестов, запуск проверок качества и т. Д., Все, что поможет получить отзыв о здоровье вашего кода). Затем вам нужно запустить сборку из последней версии источников для определенного события (изменение в хранилище, временное событие), чтобы сгенерировать отчеты и отправить уведомления о сбое (по почте, в твиттер и т. Д.).

И именно это является обязанностью механизма CI: предлагать механизмы триггеров, иметь возможность получать последнюю версию источников, запускать сборку, генерировать и публиковать отчеты, отправлять уведомления. Двигатели CI действительно реализуют это.

И поскольку сборка требует значительных ресурсов ЦП и дисков, механизмы CI обычно работают на выделенной машине (или даже на ферме машин, если вы хотите создать множество проектов).

Вернемся к вашему вопросу сейчас. После запуска Hudson настройте его ( Управление Hudson> Настроить систему ): настройте JDK, создайте инструменты и т. Д. Затем настройте Hudson Job и выполните следующие действия: настроить расположение исходного репозитория, инструмента сборки, триггера, канала уведомлений и все готово (вы можете делать более сложные вещи, но это только начало).

Для получения более подробной информации о настройке, проверьте:

• Официальный Используйте руководство Hudson для более подробной информации. << НАЧАТЬ ЗДЕСЬ </li>
• Непрерывная интеграция с Hudson - Учебное пособие .
• Раннее обнаружение дефектов при непрерывной интеграции .

Answer 2

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

---

Обновление Извините, что раньше у меня не было много времени, чтобы расширить свой ответ. @Pascal_Thivent правильно, что для того, чтобы эффективно использовать CI, вам нужно иметь возможность автоматизировать ваши сборки, тесты и т. Д. CI на самом деле является хорошей форсирующей функцией для этого. Для меня это один из тех маленьких флажков предупреждения, если я начинаю думать, что было бы слишком больно вставлять сборку в Хадсон. Это означает, что что-то не совсем правильно.

Что мне нравится в Hudson, так это то, что он достаточно гибок, чтобы приспособиться к различным рабочим процессам. Мы используем его как для сборок / юнит-тестов, так и для релизов. И это избавляет от большого беспокойства по поводу определенных процедур выпуска, работающих только в среде одного человека.

Что мне не нравится в Hudson, так это то, что он иногда нестабилен, когда новые сборки ломают плагины. У меня была пара улучшений (2 из 10 или около того), которые выходили из строя из-за несовместимости. Сейчас я делаю две вещи:

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