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

CruiseControl — различия между версиями

Материал из CustisWiki

Перейти к: навигация, поиск
м (Ссылки)
м (реплицировано из внутренней CustisWiki)
(нет различий)

Версия 14:15, 26 октября 2007

Введение

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».

Репликация: База Знаний «Заказных Информ Систем» → «CruiseControl»