Персональные инструменты
 

CruiseControl

Материал из CustisWiki

Перейти к: навигация, поиск

Введение

CruiseControl — платформа (серверное приложение) для организации непрерывной сборки написанная полностью на Java.

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

Зачем это надо

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

Если к сборке добавить еще и автоматичесикие тесты, то всегда можно быть уверенным в том, что текущая версия в CVS и работает как надо. Всю сборку и тестирование можно проводить при каждом commit`е не тратя никаких усилий (все сам сделает сервер), а возникающие ошибки и несовместимости решать сразу быстро и эффективно. Более подробные примеры использования можно найти в первых двух ссылках.

Возможности

Сервер CruiseControl имеет следующие возможности:

  • работает по расписанию или
  • следит за изменениями:
    • в репозитории CVS и многих других систем контроля версий
    • в файлах и директориях
    • в сборке других проектов
  • сам вытащит новую версию из CVS(и других)
  • соберет используя Ant, Maven, скрипт
  • опубликует результаты:
    • в зависамости от результата сборки
    • на web-сервере входящем в комплект
    • разошлет почту
    • выполнит скрипт (shell, bat)
    • выполнит скрипт Ant
    • много других способов
  • конфигурируется одним XML файлом — его тоже можно хранить под CVS

Конфигурационный файл

Это XML файл в котором описано как, когда и что должен делать CruiseControl. Самый верхний уровень это проект — все остальные настройки в нем. Проектов может быть много и они могут собираться или не собираться в зависимости друг от друга.

Внутри файла:

  • <property> — переменные или файл переменных
  • <bootstrappers> — то, что выполняется до сборки
  • <listeners> — в основном для отображения статуса на web-сервере
  • <modificationset> — за какими изменениями следить
  • <schedule> — собственно расписание сборки (см. #Цикл сборки)
  • <publishers> — публикация результатов

Цикл сборки

В цикл сборки запускается процесс-демон, который периодически выполняет действия описанные в конфигурационном файле в элементе <schedule>. Собирать проект можно:

  • скриптом
  • Maven 1 или Maven 2
  • Ant
  • NAnt

Но за один раз запускается только один сборщик, а не все подряд как этого иногда хочется(см. #Проблемы/решения). Сборщик запускается только если были обнаружены изменения описанные в <modificationset>, перед сборкой запускается <bootstrappers>.

Публикация результатов

Публикация результатов — важная часть процесса непрерывной интеграции, это единственный способ CruiseControl сообщить вам, что все хорошо/плохо. В CruiseControl есть много разных способов опубликовать результаты. Основной из них web-сервер на котором показаны результаты всех билдов и можно посмотреть их логи, для публикации на нем ничего делать не надо. В принципе от web-сервера можно отказаться, не запускать его и использовать только e-mail оповещение. Еще можно использовать другие методы публикации:

  • скрипт Ant
  • скрипт
  • выкладывание артефактов на web-сервере
  • e-mail
  • публикация статуса сборки — для последующего за ним слежения с сервера

Метод(-ы) публикации настраивается внутри элемента <publishers>.

Проблемы/решения

  • закладка с метриками не работает под Linux если нет доступа к графическому дисплею(X-консоли)
запускать CruiseControl из-под Х-консоли и блокировать консоль
  • задокументированная особенность: за раз выполняется только один билдер т. е. для такой конфигурации:
    <schedule interval="${cc.interval}">
       <exec command="sh" args="${mvn.before}"/>
       <maven2
            mvnscript="${mvn.script}" 
	     pomfile="${mvn.file}"
	     goal="${mvn.goal}"
	/>
    </schedule>

Будет выполнен ЛИБО exec ЛИБО maven2, что плохо, приходится все сливать в один скрипт. Но есть и свои преимущества можно сделать разные билды(например обычный и с тестами) и выполнять с разной частотой.

В последних версиях для удобства есть метод сборки <composite>, в который можно включать другие методы сборки. В этом случае все они будут выполнены последовательно, если не произойдет сбоя.

Ссылки

См. также



Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».