⌨ Labor omnia vincit ☮

OBS and Jenkins: a bit about continuous integration and packaging

Posted in GNU/Linux, SuSE [ru] by anaumov on 25.06.2012

Трудно представить разработку крупного 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-процессов, более стабилен в работе и настройке, и не столь требователен к ресурсам. Он так же очень прост в использовании, но не предоставляет таких возможностей для разрабтки пакетных дистрибутивов, оставаясь системой непрерывной интеграции общего назначения.

About these ads

7 Responses

Subscribe to comments with RSS.

  1. ism(unixforum) said, on 27.06.2012 at 22:45

    Ну как сказать, я не очень знаком со всем этим, но что мешает развернуть в Virtualbox виртуалки с дефолтными дистрибутивами Linux и не сделать снимки образов диска. После сботки откатывать удалением снимка. Virtualbox полностью управляется из командной строки, поэтому операции отката и создания снимков можно автоматизировать.

    • Alex said, on 28.06.2012 at 09:34

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

      Но во время разработки хотелось бы видеть отчеты, историю, кто и что закоммитил, да еще и чтобы все это через web… в общем, автоматизация процесса + создание лога, истории и т.д., это фактически изобретение тех же Jenkins или OBS.

      Я думаю, что можно было бы попробовать соединить OBS, который мы будем использовать для сборки, с Virtualbox, на котором будем тестировать то, что собрал OBS…. но это опять же изобретение велосипеда, потому что эта идея уже реализована в проекте openQA :)

      • ism(unixforum) said, on 28.06.2012 at 19:16

        А что мешает в эталонный образ систем в VirtualBox поместить некий скрипт , который при старте вирт машины или снятия ее с паузы автоматически скачивает исходники проекта , компилит их , выполняет нужные тесты и сообщает в систему мониторинга результаты тестов и логи. Готовность поставленной на паузу и под снимком работающей вирт машины мгновенная. Виртуальная машина связана с внешним мирам многими способами, например через сетевой интерфейс. А после сборки и отчетов виртуальная машина сама сбрасывается в начальное состояние и засыпает отослав готовый собранный пакет по сети

      • Alex said, on 28.06.2012 at 20:41

        А как откатиться к результатам теста n, если сейчас, к примеру, n+4?

  2. ism(unixforum) said, on 29.06.2012 at 17:13

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

    • Alex said, on 29.06.2012 at 17:58

      Тяжело говорить о целесообразности такой системы, потому что тяжело представить скорость работы и простоту ее использования (ведь “склеивать” это все нужно будет самому), но идея безусловно интересная ;)

      • ism(unixforum) said, on 29.06.2012 at 22:00

        На самом деле когда начинаешь читать перечень команд и опций командной строки, то кажется невозможного просто нет. Также можно тиражировать состояние одной машины неограниченному количеству пользователей(простым копированием папки машины и ссылкой на неизменяемый образ), а гостевая ОС будет думать , что она у каждого единственная. Это свойство VirtualBox воспроизводить состояние машины байт в байт исключает ошибки.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: