Сервер непрерывной интеграции для С++ - Что относительно зависимостей библиотек?
В настоящее время я изучаю хорошую настройку для сервера непрерывной интеграции, который будет создавать различные приложения на С++ для нескольких дистрибутивов Linux.
Мой основной вопрос: как другие пользователи здесь справляются с различиями в системных библиотеках между дистрибутивами Linux?
Хотя относительно легко создавать прямые зависимости, такие как библиотеки пользовательского интерфейса, наряду с приложением, "косвенные" зависимости, такие как glibc, выглядят как большая боль, если их нужно было создавать вместе с приложением каждый раз. Поэтому я думаю о перемещении фактического выполнения сборки в отдельную виртуальную машину для каждого дистрибутива, например. используя rlogin для запуска команд. Моя цель - предотвратить двоичную несовместимость между версиями библиотеки сборки и теми, которые были развернуты в целевых дистрибутивах.
Есть ли у кого-нибудь здесь какой-либо опыт работы с таким процессом и можно было бы сказать, является ли вышеприведенное звуковое сопровождение приемлемым?
Ответы
Ответ 1
Мы используем Jenkins (непрерывная интеграция) и CMake (система сборки) для этого цель. Дженкинс похож на Buildbot, т.е. Имеет также buildmaster и buildslaves. В настоящее время у меня есть 8 ведомых устройств для создания 4 разных платформ (FC8, FC10, FC12 и Windows 7). Мы создаем как отладочные, так и выпущенные двоичные файлы, поэтому я выделил один ведомый для каждой платформы и типа сборки.
Что касается сторонних библиотек, таких как Qt и Boost, я скомпилировал их на каждой платформе и проверил их в отдельный репозиторий.
@esavard: Мы используем CMake 2.8 для кросс-компиляции, я не использовал minigw, но быстрый поиск в Google показывает, что это возможно. Вот ссылка в учебник по перекрестной компиляции для Windows на Linux с помощью CMake и miniGW.
Я не использовал Buildbot и не могу комментировать его функции, но думал, что должен упомянуть альтернативу, которую мы сейчас используем.
Надеюсь, что это поможет.
Ответ 2
Buildbot имеет понятие buildmasters и buildslaves.
Строитель позаботится о отображении веб-графического интерфейса, отправке электронной почты, запуске сборок и других домашних заданий. Buildslaves ждут от buildmaster и когда команда будет выполнять сборки.
У нас есть buildbot, созданный для создания на нескольких разных платформах, некоторые из них VM, и он хорошо работает для нас.
Ответ 3
Конечно, buildbot и многие виртуальные машины - это путь к этому. У нас есть сервер VMWare ESX, на котором размещаются многие ведомые устройства, которые в ночное время собирают наше приложение. Затем приложение тестируется на другой виртуальной машине (а не на ведомости сборки и просто имеет установку по умолчанию ОС), чтобы убедиться, что она работает, и все зависимости упакованы.
Хорошая вещь, которую я хотел бы сделать, - сделать фазу проверки времени выполнения автоматизированным шагом, но мне еще не дано время сделать это.
