Buildbot vs hudson/jenkins для непрерывной интеграции С++

В настоящее время я использую jenkins/hudson для непрерывной интеграции большого проекта С++. У нас есть отдельные проекты для ствола и каждой ветки. Кроме того, есть некоторые связанные проекты для Java-кода, но настройка для них довольно проста прямо сейчас (мы можем сделать более позднее, хотя). Проекты С++ выполняют следующие действия:

Создает все с параметрами для того, нужно ли переконфигурировать, выполнить чистую сборку или использовать новую проверку.
Необязательно создает и запускает все тесты
Опционально запускает все тесты, используя memgrick Valgrind
Запускает cppcheck
Генерирует документацию по doxygen
Публикует отчеты: модульные тесты, valgrind, cppcheck, предупреждения компилятора, SLOC, открытые задачи и покрытие кода (с использованием gcov, gcovr и плагина cobertura)
Развертывает код в ночное время или по требованию в тестовую среду и репозиторий пакетов

Все настраивается для автоматических сборок и факультативных для сборки по требованию. Под ним есть bash script, который управляет большей частью этого, что дальше зависит от нашей системы сборки, которая использует automake и autoconf вместе с пользовательскими сценариями bash.

Мы начали использовать Hudson (в то время), потому что это то, что использовали Java-ребята, и нам просто нужны ночные сборки. С тех пор мы добавили намного больше и продолжаем добавлять больше. В некотором смысле Хадсон велик, но, конечно, не идеален.

Я посмотрел на другие решения, и единственное, что похоже, может быть заменой buildbot. Будет ли строй лучше для этой ситуации? Стоит ли инвестировать, так как мы уже используем Хадсон? Почему?

EDIT: Кто-то спросил, почему я не нашел Хадсона/Дженкинса идеальным. Короткий ответ заключается в том, что все можно улучшить. Я просто задаюсь вопросом, является ли Дженкинс лучшим текущим решением для моего варианта использования или есть ли что-то лучшее (buildbot?), Которое было бы легче поддерживать в долгосрочной перспективе, даже когда появятся новые требования.

Ответ 1

Оба являются проектами с открытым исходным кодом, но вам не нужно изменять код buildbot для "расширения", на самом деле довольно легко импортировать собственные пакеты в свою конфигурацию, в которых вы можете подклассифицировать большинство функций с помощью собственные дополнения. Примеры: ваш собственный компилятор или тестовый код, некоторый анализ выходов/ошибок, которые должны быть предоставлены следующим шагам, ваше собственное формирование предупреждающих сообщений и т.д. Есть много возможностей.

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

Также, как правило, нетрудно создать новую конфигурацию инструмента: если спецификация того, что делать (configs, builds, tests) слишком сложно переключиться с одного инструмента на другой, это ( плохой) означает, что в исходные коды перемещены не так много сценариев конфигурации. Buildbot (или Jenkins) должен вызывать только простые команды. Если просто запустить тесты, то разработчики также сделают это, и это улучшит скорость успеха, тогда как если только система непрерывной интеграции проведет тесты, вы будете работать после нее, чтобы исправить новые сбои кода, и потеряете его нерегрессионное значение, всего лишь 0,02 €: -)

Надеюсь, что это поможет.

Ответ 2

"Интеграция результатов" также находится в jenkins/hudson, и вы можете относительно легко захватывать продукты сборки, не "копировать их в другом месте".

Для нашего экземпляра все отчеты по охвату и метрики unit test и javadoc для Java-кода интегрированы. Для нашего кода на С++ плагины немного не хватает, но вы все равно можете получить большинство из них.

мы запускали buildbot с pre 0.7 и теперь выполняем 0.8 и теперь видим только настоящую причину переключения, так как buildbot 0.8 забыл о ведомых устройствах в течение длительного периода времени, а поддержка была довольно плохая.

Ответ 3

Есть много других решений, помимо Jenkins/Hudson/BuildBot:

TeamCity от Jetbrains
Бамбук по Атлантике
Перейти на Thoughtworks
Круиз-контроль
OpenMake Meister

Специфика того, что вы делаете, не так важна, на самом деле, если агенты (ака узлы), которые вы им выполняете, поддерживают эти задачи.

Красота сервера CI замечает, когда изменения сборки инициируют новую сборку (и тест), публикуют артефакты и публикуют результаты теста.

Когда вы сравниваете инструменты CI, подобные тем, о которых мы упоминали, рассмотрим такие функции, как удобство использования интерфейса, насколько легко разветвляется (и функции, которые могут предлагаться как автоматическое слияние), уведомления (например, XMPP/jabber) или информационный радиатор (например, подключить монитор, чтобы всегда показывать статус). Поддержка продукта - это еще одна вещь, которую следует учитывать - поддержка Дженкинса так же хороша, как и тот, кто отвечает на вопросы сообщества в то время, когда у вас есть вопросы.

Мой личный фаворит - Bamboo, но он поставляется с лицензией.

Ответ 4

Я давний пользователь Jenkins, занимающийся оценкой Buildbot, и хотел бы предложить несколько вещей для людей, рассматривающих возможность использования Buildbot для многомодульных решений:

*) Buildbot не имеет готовой концепции файловых artifacts связанных с каждой сборкой. Это не в пользовательском интерфейсе, и это не в любом из встроенных "шагов" модулей, насколько я вижу:

http://docs.buildbot.net/current/manual/configuration/buildsteps.html

... и я не вижу сторонних плагинов:

https://github.com/buildbot/buildbot/wiki/PluginList#steps

Buildbot собирает все выходные данные консоли из данной сборки, но, что очень важно, вы не можете собирать связанные с ней файлы.

*) Учитывая, что артефакты не поддерживаются, нелегко создать "коллекционные" проекты, которые объединяют несколько модулей, скажем, в один установщик. У Jenkins есть отличная функция, которая позволяет вам параметризовать сборку со сборками из других модулей (тип параметра - run).

*) В Buildbot сложнее установить зависимости между модулями. Допустим, у вас есть библиотека, от которой зависят три двоичных файла, и вы хотите, чтобы эти двоичные файлы перестраивались при каждом изменении библиотеки. Дженкинс имеет triggers встроенные в пользовательский интерфейс. Если вы хотите сделать триггеры в Buildbot, вы должны написать их с помощью schedulers.Dependent Зависит от этого, и это вызывает много перегрузок элементов в пользовательском интерфейсе Schedulers.

*) Когда вы работаете в Buildbot, кажется, что почти вся конфигурация выполняется в master.cfg. Это круто и расстраивает.

*) BuildBot заставляет вас создать worker в дополнение к master - серверу. Это раздражает новичков и системы, для которых достаточно одного сервера сборки.

После двух дней оценки Buildbot у меня сложилось впечатление, что мы будем придерживаться Jenkins, в первую очередь из-за наличия artifacts. Buildbot - это инструмент, который мы использовали бы, только если бы у нас были более широкие потребности в настройке и время, чтобы сделать это.