Альтернативный менеджер сборки Хадсону

Question

Я работаю в софтверной компании, где основным языком разработки является Java.Естественно, мы используем Hudson для непрерывных сборок, для которых он прекрасно работает.Однако Хадсон не так хорош в некоторых других вещах, которые мы просим сделать.Мы также используем задания Hudson для развертывания двоичных файлов, обновления баз данных, запуска нагрузочного тестирования, запуска регрессий и т. Д. Мы действительно сталкиваемся с проблемами при наличии зависимостей сборки (т. Е. Нагрузочное тестирование требует обновления БД).

Вот одна вещьчто Hudson не делает того, что нам действительно нужно:

Зависимость сборки: он поддерживает зависимости сборки для сборок Ant, но не для заданий Hudson.Мы используем функцию вызова URL, чтобы заставить задание Hudson вызывать другое задание Hudson.Проблема в том, что Хадсон всегда возвращает 200 и не блокирует, пока работа не будет выполнена.Это означает, что вызывающее задание не знает а) если сборка не удалась и б) если она не удалась, сколько времени это заняло.

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

Любое направление было бы неплохо.Возможно, мы неправильно используем Hudson (т. Е. Должны ли все сборки быть сборками Ant?) Или нам нужен другой продукт для развертывания одним щелчком, нагрузочного тестирования, миграции, обновления БД и т. Д.

Редактировать:

Для пояснения, у нас есть параметры в наших сборках, которые могут вызывать различные зависимости в зависимости от параметров.Т.е. иногда мы хотим нагрузочное тестирование с обновлением БД, иногда без обновления БД.К сожалению, создание задания Hudson для каждой комбинации параметров (как требует плагин Join) не будет работать, потому что иногда разные комбинации могут привести к десяткам заданий.

Answer 1

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

Плагин Downstream-Ext и Плагин Join позволяют более сложно определить зависимости сборки.

Answer 2

Существует интерфейс командной строки для Hudson, который позволяет вам выдавать команды экземпляру Hudson. Используйте «помощь», чтобы получить точные детали. Я считаю, что есть такая, которая позволяет вам вызывать сборку и ждать ее окончания.

http://wiki.hudson -ci.org / дисплей / HUDSON / Hudson + CLI

Answer 3

Вам нужна дополнительная работа для ваших «зависимостей»?

Ваши зависимости звучат для меня как дополнительный шаг сборки. Сценарий, который обновляет БД, может быть сохранен в вашей scm, и каждая сборка, которая нуждается в этом шаге, проверит его. Вы можете вызвать этот скрипт, если ваш параметр "db refresh" имеет значение true. Это можно сделать с помощью нескольких модулей. В чем преимущество? Логика вашего скрипта в вашей scm (всегда хорошо иметь историю изменений). У вас все еще есть возможность обновить скрипт один раз для всех ваших тестовых заданий (так как все проверяют один и тот же скрипт). Кроме того, вам не нужно просматривать несколько сценариев, чтобы выяснить, успешно ли прошел ваш тест. Особенно, если у вас есть одно задание, являющееся частью нескольких строк выполнения, становится трудно определить, какое задание сработало, какое выполнение. Еще одним преимуществом является то, что у вас меньше рабочих мест в Hudson, и поэтому его легче обслуживать.

Answer 4

Я думаю, что вы ищете это http://wiki.jenkins -ci.org / display / JENKINS / Параметризованный + Триггер + Плагин Этот плагин позволяет вам выполнять другие задания в зависимости от состояния предыдущих заданий. Вы даже можете вызвать сценарий оболочки из нижестоящего проекта, чтобы определить любые дополнительные условия. который в свою очередь может вызвать API для получения дополнительной информации.

Например, у нас есть шаг после сборки, чтобы уведомить нас, это вызывает JSON API для создания хорошей темы в нашем канале IRC, которая говорит: «Все сборки в порядке» или «X, Y не удалось» и т. Д.