Дженкинс + Cmake + JIRA = CI нескольких взаимозависимых проектов?

Question

В нашей системе есть ряд небольших проектов, работающих на Linux (Slackware 7-11, медленно переходящий на RHEL 6.0). Около 50-100 приложений и 15-20 библиотек. Почти все наши приложения используют одну или несколько наших библиотек. Наше исходное дерево выглядит примерно так:

/app1
/app2
/app3
/include
/foo/app4
/foo/app5
/foo/app6
/foo/lib1
/foo/lib2
/lib/lib3
/lib/lib4
/lib/include

Теперь я проделал некоторую работу по созданию некоторых файлов CMakeLists.txt и собрал большую часть библиотек и некоторых приложений. Мне довольно удобно использовать cmake для сборки. Я сделал это с v2.6, и недавно (час назад) обновился до 2.8. Каждый из вышеперечисленных проектов имеет свой собственный файл CMakeLists.txt, специфичный для проекта, который выполняет сборку и установку (пока нет упаковки).

У меня есть требование использовать и обеспечивать непрерывную интеграцию. Я установил и поиграл с Дженкинсом, и от того, что я видел, я очень впечатлен. Я также оцениваю JIRA для отслеживания проблем.

Просто чтобы начать работу, я установил cmake на все библиотеки, чтобы приложения могли найти их в файловой системе. Заголовки устанавливаются в / usr / local / include и встраиваются в / usr / local / lib. Это плохо делать? Было бы лучше сказать cmake искать исходный каталог библиотеки, использовать интерфейс экспорта или недавно представленный ExternalProject_Add ?

Поскольку я собираюсь использовать Jenkins, я не могу гарантировать, что cmake сможет найти каталог с исходным кодом или сборкой. Конечно, я могу сказать Дженкинсу построить проекты по порядку (или, по крайней мере, сначала построить зависимости). Если обновление библиотеки нарушит построение другого проекта, то я думаю, что это будет кто-то с 3/4 сообразительности, чтобы определить это.

Заранее спасибо

Answer 1

Просто чтобы начать работу, я установил cmake на все библиотеки, чтобы приложения могли найти их в файловой системе. Заголовки устанавливаются в / usr / local / include и встраиваются в / usr / local / lib. Это плохо делать?

Нет, это не плохо, но ваша сборка должна воспроизводить ресурсы с нуля. Такие вещи, как переносимость и исправление ошибок сборки, станут проблемой, если эти вещи необходимо предварительно установить в системе вне процесса сборки. Если вы можете сделать это другими способами, как вы упомянули, я бы предложил этот путь, но если это сделает вашу сборку намного длиннее, это то, что вам нужно почувствовать. Моя идеология заключается в том, что все должно быть перенесено на новую машину Jenkins со свежей установкой в ​​мгновение ока, опять же, это всегда не достижимо, но есть к чему стремиться.

Поскольку я собираюсь использовать Дженкинс, я не могу гарантировать, что cmake может найти исходный каталог или каталог сборки. Конечно могу сказать Дженкинс строить проекты в порядке (или, по крайней мере, построить зависимости в первую очередь). Если обновление библиотеки нарушает здание другой проект, тогда я думаю, что это будет кому-то с 3/4 остроумия чтобы определить это.

Ну, одна из вещей, которые я делаю во взаимозависимых заданиях, заключается в том, что при успешном построении одного задания запускается задание, которое зависит от него. Так, например, если A зависит от B, а A терпит неудачу, B никогда не будет запущен, и тот, кто создал проблему в сборке A, будет отвечать за нее и так далее. Это предотвращает каскадный эффект неработающей сборки, которая была вызвана нарушенной зависимостью. Я бы посоветовал вам хранить файлы в конкретной сборке в его папке заданий и указывать для зависимости расположение необходимых файлов. Снова держите ваши сборки отдельно и чистыми.

Я также оцениваю JIRA для отслеживания проблем.

Я настоятельно рекомендую JIRA в качестве системы отслеживания проблем для компании; Возможно, вы захотите взглянуть на этот плагин Jenkins для интеграции. Если вы используете git, и вы не против разместить свой код вне сайта, я бы также сделал GitHub.

Удачи, ты, кажется, на правильном пути.