OBS and Jenkins: a bit about continuous integration and packaging

Трудно представить разработку крупного software-проекта без системы непрерывной интеграции. Они являются неотъемлемой частью инфраструктуры любой software-компании. Уже около года я использую параллельно две open source системы: Jenkins и OBS. Являются ли они взаимозаменяемыми, какая для каких проектов больше подходит и на какую стоит обратить внимание, я расскажу в этой небольшой статье. Задача, которую я ставил перед обоими системами, достаточно тривиальна для большинства software-компаний: пересборка новых RPM/DEB-пакетов после svn-/git-коммитов группы разработчиков, и скалыдвание их в определенном порядке в соответствующие репозитории.

Who is who?

Проект Open Build Service (первоначально openSUSE Build Service) был начат в главном отделении SUSE/Novell, как платформа для разработки дистрибутива openSUSE/SLE, и впервые был представлен на FOSDEM в 2006 году. Все компоненты OBS являются Free Software. Проект поддерживают такие организации и компании как Linux Foundation и AMD, а так же имеет большое дружное сообщество. Написан на perl/ruby/python.
Разработка Jenkins (первоначально Hudson) была начата в Sun Microsystems. Проект, как того и стоило ожидать, целиком написан на Java. Распространяется по MIT-лицензии.

OBS представляет из себя абсолютно самодостаточную development-платформу. Развернув её вы получите в свое распоряжение не только систему управления версиями, семантика которой идентична svn/cvs/git, но и репозиторий с новоиспеченными пакетами, который будет автоматически создан/обновлен после каждой удачной сборки. Jenkins в этом плане представляет из себя более модульную систему. Вам придется во-первых настроить svn/cvs/git-хранилище, во-вторых для создания репозитория придется также немного поколдовать (еще одно “shell-правило”). С другой стороны, если проект был создан до установки Jenkins, то это как раз то, что вам нужно, а вот интеграция такого проекта с OBS потребует доустановки специальных дополнений, синхронизирующих его хранилище с svn или git. Для обоих систем есть большое количество плагинов, расширяющих их возможности.

Time of build

OBS собирает пакет в свежем окружении выбранного дистрибутива, учитывая зависимости и архитектуру. Процесс сборки одного пакета длится около 3-5 минут (все это время уходит в основном на установку окружения). Это не гарантирует корректной работы пакета. Pre/Post-скрипты не запускаются, а это значит, что даже если вы успешно пересобрали пакет, он все равно может быть сломаным. К сожаленью, OBS так же не предусматривает добавление тестов, которые должен пройти пакет. Другими словами, стабильность работы пакета полностью ложится на плечи команды QA.
Кстати, изменив один файл в проекте, работая через WebUI, OBS запускает новый build-процесс, потому что воспринимает это как новый коммит (build-процесс запускается автоматически после каждого коммита). Таким образом, если вам надо будет изменить более одного файла, вы постоянно будете обрывать предыдущий build-процесс, начатый после предыдущего коммита автоматически. При сборке RPM это не так критично, но в случае сборки DEB-пакетов, где, к примеру, номер версии пакета находится в двух файлах и должен быть одинаковым, это будет происходить постоянно. Чтобы этого не происходило используйте osc, где у вас есть время подумать после исправления первого файла и перед изменением второго, и лишь после этого сделать коммит.

Jenkins не предоставляет каких-либо специальных вкусняшек для сборки пакетов. Собирать их можно самым обычным образом через dpkg -deb или rpmbuild. У этого метода есть одно преимущество – скорость сборки. На один пакет уйдет паку секунд. Для этого надо просто создать каталог со структурой, который будет иметь пакет. Pre/Post-скрипты так же запущенны не будут, так что удачи при тестировании.
Стоит отметить, что хоть обе системы и не тестирует новоиспеченные пакеты, мы можем добавить целую группу shell-правил (при использовании Jenkins) или просто написать скрипт, используеющий osc (при использовании OBS), так или иначе эмулирующих эти тесты.

Resources

В связи с тем, что OBS является более профессиональной системой, специально заточенной для сборки пакетов, он сначала создает псевдосистему, в которой после и происходит сборка пакета. Это дает незаменимое преимущество при разработке сложных систем, состоящих из группы пакетов (дистрибутивов). Тут, как я писал выше, учитывается и архитекрура, и связи с другими пакетами, которые уже установленны в системе. Как вы понимаете, для развертывания такой системы нужны ресурсы. Для каждой сборки OBS требует один CPU_CORE. К примеру, вам надо собрать два разных пакета для Debian и Ubuntu, для 32- и 64-битной архитекруры. Для параллельной сборки понадобится 8 ядер. Я не знаю точно сколько разработчики советуют использовать RAM для каждой сборки, но по моему наблюдению меньше одного гигабайта на один build-процесс лучше не выделять.
Jenkins не соберет пакет для ARM или PowerPC, он так же не скажет вам, что файл с таким именем создать нельзя, потому что в системе уже существует файл с таким именем, и принадлежит он другому пакету. Если вы занимаетесь разработкой проекта, установка которого никак не влияет на систему (к примеру, не будут измененны/перезаписанны системные файлы), то Jenkins’ом вполне можно обойтись. Это может быть, к примеру, Java-проект, код которого протестирует Jenkins во время сборки, соберет проект, после чего мы получим jar-архивы, и положит эти jar-архивы в пакет. При установке все эти архивы будут просто скопированы в нужный нам каталог. Для сборки такого проекта не нужна псевдосистема, разворачиваемая OBS’ом для каждого пакета, следовательно нам не надо ждать 3-5 минут и тратить на это такие ресурсы. Нам надо просто запаковать наш каталог в deb или rpm-архив. Jenkins сделает это за пару секунд, даже если вы выделите ему всего один гигибайт на все про все.

Conclusion

OBS предоставляет очень интересные возможности для профессиональной архитектурно-зависимой сборкой сложных пакетных систем. Платой за это являются потребляемые им ресурсы, некоторые проблемы, которые могут возникнуть при обновлении OBS, а так же обучение персонала работе с osc. Jenkins более наглядно показывает историю build-процессов, более стабилен в работе и настройке, и не столь требователен к ресурсам. Он так же очень прост в использовании, но не предоставляет таких возможностей для разрабтки пакетных дистрибутивов, оставаясь системой непрерывной интеграции общего назначения.