Создание build server на основе Hudson CI

Мотивация

Проекту, сборку которого мне пришлось автоматизировать, очень много лет. Встала задача его небольшой модернизация под нужды заказчика. Согласно договорённостям, мы выдавали обновлённый дистрибутив где-то раз в неделю. К тому же в команде появился тестер. Ему свежий дистрибутив нужен был несколько чаще.
Этапы сборки дистрибутива:

1. обновить исходники;
2. записать номера текущей ревизии в специальный h-файл;
3. собрать проект;
4. сохранить файлы символов и бинарных файлов для отладки по дампам;
5. сборка файлов справки;
6. собрать все файлы, необходимые для дистрибутивы, в одном месте;
7. собрать дистрибутив;
8. очистить временные файлы.

Человек, занимающийся сборкой, делал всё это вручную! Время уходило много. Если что-то где-то шло не так, то для выяснения причин приходилось просматривать множество разношёрстных логов в десятки килобайт. На выходе этого процесса получается файл setup.exe и выяснять, чем он отличается от предыдущего, становилось достаточно проблематично.
В один прекрасный день, я случайно набрёл на статью Андрея Сатарина «Введение в непрерывную интеграцию или каша из топора». В ней обосновывается польза использования сервера непрерывной интеграции, даже в отсутствии автоматизированных тестов. И понял – это наш случай. В результате некоторых раздумий была сформулирована основная задача: сделать так, что бы запускать процесс сборки дистрибутива одним кликом, а потом посмотреть консолидированный отчёт по всем этапам.

Реализация

Если Вы пишете на Java, .NET или другой популярной платформе, то у Вас есть масса готовых решений для организации build server. А что выбрать, если Ваш проект собирается набором разнообразных программ? После изучение возможностей популярных продуктов были сформулированы требования к системе:

1. умение работать с системой контроля версий SVN;
2. умение запускать бинарные файлы;
3. наличие средства работы выводом консоли.

Выбор пал на Hudson CI. Это программа написана на Java. И, на первый взгляд, для Java. Но это нет так. Система плагинов делает эту систему практически универсальной. К другим плюсам можно отнести:

• бесплатность;
• наличие плагинов почти на все случаи жизни;
• возможность написания своих плагинов;
• простота запуска и настройки;
• постоянное обновление;
• большое число пользователей.

Сервер разворачивался на Windows 7 Professional, т.к. это целевая система для нашего проекта. Для запуска java-приложений необходимо установить JRE. Ну поехали…
Создаем папку hudson. Переписываем файл дистрибутива в эту папку. Запускаем java –jar hudson.war. Всё – система запущена. Это простота мне очень понравилась.
Замечание. Чтоб каждый раз не запускать Hudson вручную, можно установить его как сервис Windows. Сделать это можно прямо из панели настройки системы. Правда, после этого наш проект перестал собираться. Какие-то проблемы с путями.
Теперь настроим её. Открываем любимый браузер, вводи адрес 127.0.0.1:8080. Вы должны увидеть примерно такую картину.

Если чего-то не работает, попробуйте отключить фаейрвол. Мне помогло.
Щелкаем Настроить Hudson. Если Ваш сервер подключён к интернету, то на этой странице можно установить любые плагины, обновить уже установленные, ну и обновить сам Hudson. Нам понадобиться плагины Batch task, Copy Archiver, Subversion, Log Parser. У всех них есть свое предназначение. Отмечаем галочкой нужные плагины и жмём кнопку «Установить» в конце страницы.

Создаём новый проект. Ссылка Новая задача на главной странице. Вводим имя проекта и выбираем шаблон. Нам больше всего подходит первый вариант.

Первая задача – это обновить исходники. В разделе «Управление исходным кодом» выбираем нужную SCV, и настраиваем её. Наш проект хранится в репозитории Subversion. Достаточно ввести url транка, чтобы Hudson знал, где брать исходные тексты для сборки.

Проверим. Нажимаем Собрать проект. Если Вы не меняли настройки Hudson, то в папке c:\Users\UserName\.hudson\jobs\ProjectName\ должна появиться пака workspace, а в ней – исходные тексты нашего проекта. На панельки слева отображаются уже выполненные сборки.

Кружочек слева от названия говорит о статусе сборки: успешная, не удачная, в процессе и т.д. Щелкнув на ссылку, можно рассмотреть сборку более подробно.

По центру экрана отображается сводная информация по сборке. В разделе Вывод консоли можно посмотреть что было сделано.

В исходные тексты программы добавим пакетный файл, который с помощью программы SubWCRev записывает номер текущей ревизии в h-файл. Осталось его запустить. Для этого, в настройках проекта, в разделе «Сборка» нажимаем «Добавить шаг сборки» -> «Выполнить команду Windows».

В скриптах можно использовать специальные переменные, такие как %WORKSPACE% (указывает на исходные тексты).
Следующая задача – собственно сборка. Специального плагина для сборки проектов VС++ 6.0 я не нашёл. Поэтому был написан очередной bat-файл. Добавим в сборку ещё одну команду Windows.

Не забываем нажать «Сохранить» в конце страницы. Запускаем сборку. Если всё собралось, то любуемся синим кружочком и радуемся. А если нет. Как понять где ошибка? Какой компонент не собрался? Мотать лог в тысячи строк в поисках сообщения об ошибке – крайне нудное занятие. Поручим его специальному плагину - Log Parser. Это плагин парсит лог сборки в поисках строк отвечающих заданному регулярному выражению, и идентифицирует их как ошибки или предупреждения. Настроим этот плагин. В настройках проекта, в разделе «Console Output Parsing» щёлкаем «Добавить». Для каждого правила задаётся его имя и файл его заданием. Это файл состоит из строк вида тип_строки /регулярное_выражение/. Например:
error /: error/
warning /: warning/
Путь до файла должен быть абсолютный.

Сохраняем. Теперь настроим проект, чтобы после сборки парсился лог, согласно нашим правилам. Переходим на страницу проекта, далее Настроить проект. В разделе «Послесборочные операции» выбираем «Console output (build log) parsing». Если правил много – можно выбрать одно из них.

Для проверки специально добавляем ошибку в код, и запускаем сборку. После сборки переходим на страницу с её описанием.

Оно уже более информативно. Мы видим изменения (из лога SVN) со времени последней сборки. И отчет по ошибкам. Их у нас целых 17. Чтобы узнать подробности, щелкнем слева Parsed Console Output.

Последующие шаги сборки реализуются запуском пакетных файлов.
Аппетит приходит во время еды. Хотелось бы выложить дистрибутив в какое-нибудь общедоступное место. Для этого нам понабиться плагин Copy Archiver. Если у Вас он установен, то в разделе настроек проекта «Послесборочные операции» появится пункт «Aggregate the archived artifacts». Стаим галочку, и настриваем что куда должно переписаться. В поле «Shared directory» указываем каталог, в который нужно положить готовый дистрибутив. Проверьте, что пользователь, от имени которого будет запущен hudson имеет право записывать в эту дирректорию. В «Artifacts to copy» задаём что копирывать. Путь указывается относительно дирректории worckspace, куда были выгружены исходники. Если не поставить галочку «Flatten», то бутдет восоздана структура вся каталогов.

Иногда нужно сохранять некоторые дистрибутивы. Например, те, которые отдаются заказчику. Сохранять все – слишком большая трата места, да и не нужны они никому. Поэтому нужен плагин, который будет выполнять определённые действия по требованию. Batch task – вот решение наших проблем. Если поставить этот плагин, то в первой группе настроек проекта появиться опция Batch tasks. Ставим галочку и добавляем действия, которые будем выполнять по требованию. Для каждого действия задаётся имя и скрипт. В скрипте можно использовать переменные с номером ревизии, билда и т.д.

На странице проекта появилась ссылочка Task. Щелкаем её и видим список возможных действий.

Выбираем нужное действие и нажимаем Build Now. И последний собранный дистрибутив скопирован в специальное хранилище. Я организовал такое хранилище прямо на этом же сервере.

Что дальше

Нужно разбираться c авторизацией, правами доступа и т.д. В текущей конфигурации любой желающий может производить любые действия.
Хотелось бы добавить автоматическое тестирование. Для этого следует использовать специализированные продукты и настроить их взаимодействие с Hudson.
Рассмотреть возможность интеграции с Hudson с системами управления проектами.

Литература

1. Андрей Сатарин “Введение в непрерывную интеграцию или каша из топора”
2. Hudson Wiki
3. Другой пример использования Hudson