Совершенствуем процесс сборки при помощи IBM Rational Build Forge: Часть 2. Автоматизируем процесс сборки для реального...

Источник: IBM

Ян Лим

Описание: Изучив учебное руководство, вы узнаете, каким образом Rational Build Forge может расширить стандартный процесс компиляции и сборки за счет добавления средств пользовательской настройки и развертывания. Переходим от неавтоматизированных методов к автоматизации: проверки на наличие изменений кода, получения самого актуального исходного кода, компиляции и упаковки, настройки, копирования файлов на сервер развертывания и перезапуска сервера, и, наконец, отправки уведомлений по электронной почте о доступности новой версии. В этой серии рассказывается о том, как реализовать систему управления сборками, которая будет использовать и расширять уже имеющиеся в вашей среде автоматизированные технологии. Изучение данной серии из двух статей позволит вам повысить показатели производительности с 0 до 96 bpd (builds per day, сборок в день) за два дня.

ПЕРЕД НАЧАЛОМ РАБОТЫ

В 1-й части данной серии мы установили систему Rational Build Forge и попробовали удаленно управлять сборкой программы Hello World. В этой части учебного руководства вы узнаете, как выполнить сборку реального проекта Jakarta Tomcat. Tomcat - один из самых успешных проектов с открытым исходным кодом в мире. Он представляет собой ядро исполнения сервлетов, которое используется в крупных и малых производственных средах..

Цели

День второй. В процессе изучения данного учебного руководства вы узнаете, как:

выполнить сборку проекта Tomcat с нуля;
автоматизировать сборку при помощи Build Forge;
дополнить управление сборками процессом развертывания Tomcat;
добавить автоматизированную пользовательскую настройку в параметры развертывания;
получить актуальную версию кода Tomcat из репозитория;
настроить Build Forge на периодическую проверку обновлений кода и запуск сборок при их наличии.

Необходимые условия

Предполагается, что вы уже закончили изучение 1-й части данной серии. Кроме того, мы предполагаем, что вы имеете представление о сборке Java-приложений. Среда Build Forge не зависит от конкретного языка программирования, но проект Tomcat написан на языке программирования Java. Опыт работы с Apache Ant и Subversion полезен, но не обязателен.

Требования к системе

Для выполнения примеров учебного руководства необходимо установить следующее программное обеспечение:

Java jdk 5 update 12
Subversion win 32 1.4.5
Apache Ant 1.7.0
Исходный код Tomcat 6.0.14

Это не самые последние версии Java, Ant и Subversion. Первоначальные попытки выполнить сборку Tomcat при помощи Java 6 не увенчались успехом. Решению проблемы могло бы помочь изменение свойств сборки, но подобные действия могли бы усложнить изучение данного руководства.

Для сборки проекта Tomcat и подключения к репозиторию Tomcat Subversion необходимо подключение к сети Интернет.

УСТАНАВЛИВАЕМ НЕОБХОДИМОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

Если в вашей системе не установлены JDK, Apache Ant или Subversion, не беспокойтесь. Их совсем несложно установить. Самая распространенная ошибка - не включить каталог bin для каждого продукта в переменную окружения path. В результате при вводе команды ant в командной строке мы получим следующее сообщение:

'ant' is not recognized as an internal or external command, operable 
program or batch file
 (команда 'ant' не является внешней или внутренней командой,
  работоспособной программой или командным файлом).

Убедитесь в том, что путь к каталогу bin отображается в значениях системной переменной окружения path.

PATH=C:\Program Files\Windows Resource Kits\Tools\;C:\WINDOWS\system32;
C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Rational\common;
C:\Program Files\MySQL\MySQLServer 5.0\bin;
c:\Program Files\Java\jdk1.5.0_12\bin;C:\apache-ant-1.7.0\bin;C:\svn\bin;

Необходимо также добавить переменные окружения ANT_HOME и JAVA_HOME. Эти переменные окружения, как и path, устанавливаются через Control Panel (Панель управления) > System (Система) > Advanced (Дополнительно) > Environment Variables (Переменные среды).

Установив JDK, Ant и Subversion, проверьте их работоспособность; для этого откройте новое окно командной строки, перейдите в каталог C:\ и введите следующие команды:

Программа	Команда	Ожидаемый вывод
Java JDK	`javac -version`	`javac 1.5.0_12 javac: no source files Usage: javac <options> <source files>`
Apache Ant	`ant -version`	`Apache Ant version 1.7.0 compiled on December 13 2006`
Subversion	`svn --version --quiet`	`1.4.5`

ВЫПОЛНЯЕМ СБОРКУ TOMCAT ИЗ КОМАНДНОЙ СТРОКИ

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

Распакуйте файл архива с исходным кодом в каталог и воспользуйтесь Ant для запуска скриптов сборки Tomcat.

Распакуйте файл apache-tomcat-6.0.14-src.zip в каталог c:\tomcat_build.
Откройте окно командной строки и перейдите в каталог C:\tomcat_build\apache-tomcat-6.0.14-src.
Первая задача Ant, которую необходимо выполнить, просто загружает зависимые библиотеки. Это подготовительное действие, которое выполняется один раз. Последующие сборки вы будете указывать в каталоге загрузки, об этом мы поговорим позже.
Введите команду ant download; эта команда вызывает цель download в скрипте build.xml в текущем каталоге.

Если прежде вам не приходилось работать с Ant, то это может показаться немного непонятным. По умолчанию Ant использует файл build.xml в текущем каталоге. Вы можете открыть этот файл в любом текстовом редакторе и найти цель download, чтобы проследить путь исполнения.
Проверьте успешность выполнения подготовительной задачи Ant. Команда Ant download возвращает множество строк вывода. Самое важное находится в конце вывода: это сообщение BUILD SUCCESSFUL или BUILD FAILED.
Если в выводе на этом этапе вы обнаружили сообщение BUILD FAILED, то причина, скорее всего, в том, что Ant вообще не может установить соединение с интернетом, или ресурс, который пытается загрузить скрипт, был перемещен на зеркало, на которое еще не создана ссылка.
На момент написания данного учебного руководства файл eclipse-JDT-3.2.2.zip, на который есть ссылка в скрипте, был перемещен с сервера http://sunsite.informatik.rwth-aachen.de, следовательно, сборка не была выполнена (BUILD FAILED). Выполнив поиск альтернативного зеркала в Google, мы отредактировали файл build.properties.default при помощи блокнота, заменив ссылку http://sunsite.informatik.rwth-aachen.de ссылкой http://mirrors.ibiblio.org/pub/mirrors, как показано на следующем рисунке.
После повторного запуска команды ant download вы должны увидеть следующий вывод:
Просмотрите содержимое каталога c:\usr\share. Подготовительная задача download создает каталог c:\usr\share и помещает в него библиотеки, которые необходимы для сборки Tomcat.
После этого можно выполнить сборку Tomcat. У нас есть необходимые библиотеки в каталоге c:\usr\share, и мы можем запустить главную цель сборки в файле build.xml. Убедитесь, что находитесь в каталоге C:\tomcat_build\apache-tomcat-6.0.14-src и введите команду ant (без дополнительных аргументов).
Проверьте успешность выполнения задачи Ant.
Только что созданные двоичные файлы размещены в файловой системе. Мы создали двоичные файлы Tomcat с нуля! Кроме того, в структуре каталога tomcat_build появился каталог output.

Тестирование

Теперь необходимо проверить, можно ли использовать файлы, созданные процессом сборки. По умолчанию, сервер Tomcat запускается на порту 8080. Если этот порт используется каким-либо другим приложением, то запуск не будет выполнен. Предположим, что порт 8080 свободен, и мы можем запустить tomcat.

В командной строке из каталога C:\tomcat_build\apache-tomcat-6.0.14-src\output\build\bin введите команду startup.

При запуске Tomcat из командной строки будет открыто отдельное окно, которое останется открытым после запуска. Если при запуске произойдет какая-либо ошибка (например, в момент запуска выяснится, что порт используется), то окно закроется раньше, чем вы сможете его увидеть. Чтобы понять причину неудачи, запустите утилиту catalina run, которая сохранит вывод в текущем окне; это поможет найти причину проблемы.

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

Подключитесь к Tomcat через Web-браузер

Откройте в Web-браузере http://localhost:8080/, чтобы просмотреть страницу администрирования Tomcat по умолчанию.

Отключаем сервер

В этом учебном руководстве мы несколько раз будем выполнять повторные сборки и перезапуски сервера Tomcat. Пока завершите его работу, выполнив команду shutdown из каталога C:\tomcat_build\apache-tomcat-6.0.14-src\output\build\bin, или закрыв окно, которое было открыто командой startup.

Дополнительный контроль над процессом сборки

Использование параметров по умолчанию дает результаты, но это не совсем то, что нужно. Важнее всего то, что по умолчанию вывод записывается в каталог, в котором находится файл Tomcat build.xml (используется относительное указание пути). При повторной сборке Tomcat предыдущая сборка будет перезаписана (или останется без изменений, если сборка не была выполнена). После этого будет невозможно понять, какая версия или сборка с каким номером создала двоичные файлы в каталоге output.

Чтобы контролировать такие моменты как каталог записи вывода, необходимо создать текстовый файл с именем build.properties в каталоге C:\tomcat_build\apache-tomcat-6.0.14-src и добавить в него следующие значения:

tomcat.build=c:/temp/output/build
tomcat.classes=c:/temp/output/output/classes
tomcat.dist=c:/temp/output/output/dist
tomcat.deployer=c:/temp/output/output/deployer
tomcat.extras=c:/temp/output/output/extras
tomcat.release=c:/temp/output/output/release

Кроме того, нам нужна возможность запускать команду ant, не находясь в каталоге C:\tomcat_build\apache-tomcat-6.0.14-src.

Перейдите в корневой каталог: cd \
Введите команду ant -buildfile c:\tomcat_build\apache-tomcat-6.0.14-src\build.xml
Убедитесь, что вывод был записан в каталог C:\temp\output в соответствии с параметрами в файле build.properties.

Теперь мы контролируем процесс сборки Tomcat настолько, чтобы настроить автоматизацию при помощи Build Forge. Мы добились такого уровня контроля, не изменяя скриптов сборки Tomcat.

ВЫПОЛНЯЕМ СБОРКУ TOMCAT ПРИ ПОМОЩИ BUILD FORGE

В 1-й части мы создали в Build Forge проект Hello World и воспользовались консолью управления Build Forge Management Console для выполнения команд при помощи удаленного агентского компонента. Теперь мы создадим более полную конфигурацию сборки для выполнения сборки Tomcat. С этой целью мы создадим группу окружения Build Forge для хранения параметров, а также проект и шаг в проекте для выполнения Ant-скрипта Tomcat с правильными параметрами.

До сих пор все, что касалось сборки Tomcat, выполнялось вручную. В этом разделе мы начнем раскрашивать зеленым цветом ячейки в столбце "Автоматизированные" напротив автоматизированных задач.

Создаем проект

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

Перейдите в категорию Projects.
Введите Tomcat в поле Name.
Убедитесь, что в поле Selector по умолчанию выбрано значение build selector.
Нажмите кнопку Save Project.

Creating a project steps

Создаем тег project

Build Forge позволяет контролировать имя каждой сборки в проекте при помощи тега project . Для проекта Tomcat настройте этот тег таким образом, чтобы он отображал версию Tomcat, сборка которой выполняется (версия 6), и порядковый номер сборки, который будет увеличиваться при каждом выполнении сборки. Теги позволяют отличать сборки друг от друга и управлять размещением вывода для каждой сборки. Теги для первых двух сборок будут TC_6_BUILD_1, TC_6_BUILD_2 и т.д.

Нажмите кнопку edit рядом с только что созданным проектом Tomcat.
Перейдите на вкладку Tags.
Введите в поле Tag Format значение TC_$TCVER_BUILD_$B.
Введите TCVER в поле Tag Name и 6 в поле Initial Value.
Нажмите кнопку Create.
Нажмите кнопку Save Project.

Creating a project tag

Создаем группу окружения проекта

Группа окружения будет содержать все параметры, необходимые для управления сборкой. Группы окружения в Build Forge предоставляют уровень абстракции, который:

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

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

Для примера в этом учебном руководстве нам необходима группа окружения, которая будет использоваться каждым шагом в проекте Tomcat. Эта группа будет содержать свойства, которые были определены ранее в файле build.properties при запуске сборки вручную из командной строки.

Создаем группу окружения

Перейдите в категорию Environments.
Введите tomcat_build_properties в поле Name.
Нажмите кнопку Save Environment.

Вводим параметры группы окружения

После того как вы нажали кнопку Save Environment в предыдущем шаге, окно программы изменилось. Теперь мы можем отредактировать параметры группы окружения tomcat_build_properties. Используйте эту панель для создания необходимых свойств. Первое свойство, которое нужно определить, будет управлять каталогом записи вывода, созданного в процессе сборки. Здесь в ручной процесс сборки необходимо внести значительное усовершенствование. Неавтоматизированный процесс сборки всегда записывает вывод в один и тот же каталог output, что может обусловить ряд проблем:

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

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

Введите в поле Name output_dir и C:/build/$BF_PROJECTNAME/$BF_TAG/output в поле Value.
Нажмите кнопку Save Variable.

При каждом выполнении сборки значения $BF_PROJECTNAME и $BF_TAG будут выбираться из проекта. Допустим, например, что для первой сборки файлы должны быть созданы в каталоге c:\build\Tomcat\TC_6_BUILD_1\output. Поскольку эти значения являются динамическими, то параметр группы окружения, который мы создали, можно повторно использовать для любого проекта без каких-либо изменений.

Создаем остальные переменные группы окружения

Остальные переменные будут повторно использовать переменную output_dir для экономии времени на ввод информации и повышения удобства обслуживания проекта. Мы также добавим переменную для управления портом, который будет прослушивать сервер Tomcat после успешной сборки и развертывания.

Имя	Значение
tomcat.build	$output_dir/build
tomcat.classes	$output_dir/classes
tomcat.dist	$output_dir/dist
tomcat.deployer	$output_dir/deployer
tomcat.extras	$output_dir/extras
tomcat.release	$output_dir/release
target_port	8081

Ассоциируем группу окружения с проектом

Связь между группой окружения и проектом создается на вкладке Project Details.

Перейдите в категорию Projects.
Нажмите кнопку edit рядом с проектом Tomcat в списке проектов.
Выберите в поле Environment значение tomcat_build_properties.
Нажмите кнопку Save Project.

Чтобы открыть список шагов проекта Tomcat, нажмите ссылку Tomcat в списке проектов.

Создаем шаг проекта

Теперь у нас есть переменные, необходимые для того, чтобы выполнить сборку и получить вывод в разных каталогах при каждом выполнении. Теперь нам нужно указать команды командной строки, необходимые для выполнения сборки. Может показаться, что нам нужна всего одна команда (та, что мы вводили ранее в командной строке), но на самом деле нам необходимы две команды.

Из-за особенностей механизма использования командной оболочкой Ant переменных окружения в скриптах сборки Tomcat недостаточно, чтобы эти переменные просто существовали в памяти (это обеспечивает Build Forge). Они должны на самом деле считываться Ant в процессе сборки. В Tomcat, как и в любом другом внешнем проекте, вы не можете диктовать разработчикам, как они должны писать сценарии сборки, поэтому придется работать с тем, что есть. Механизм, который рабочая группа Tomcat выбрала для извлечения параметров, основан на импорте файла свойств, поэтому нам нужно сначала создать такой файл и внести в него параметры сборки.

1. Введите Create build properties file в поле Name.

2. Убедитесь, что в поле Path по умолчанию выбрано значение Relative.

3. В поле Command введите нижеследующий текст, а в остальных полях оставьте значения по умолчанию.

echo base.path=%base.path%> temp.properties
echo tomcat.build=%tomcat.build%>> temp.properties
echo tomcat.classes=%tomcat.classes%>> temp.properties
echo tomcat.dist=%tomcat.dist%>> temp.properties
echo tomcat.deployer=%tomcat.deployer%>> temp.properties
echo tomcat.extras=%tomcat.extras%>> temp.properties
echo tomcat.release=%tomcat.release%>> temp.properties

4. Нажмите кнопку Save Step.

Создаем шаг сборки

На предыдущем шаге был создан файл temp.properties. Теперь мы создадим шаг, который ссылается на этот файл, а также на файл build.xml, который мы запускаем из командной строки.

Введите в поле Name Build Tomcat.
Введите в поле Command строку ant -propertyfile temp.properties -buildfile c:\tomcat_build\apache-tomcat-6.0.14-src\build.xml .
Нажмите кнопку Save Step.

Запускаем проект

Нажмите кнопку Start Project.
Нажмите кнопку Execute. Обратите внимание на значения переменных окружения проекта.

На экран будет выведено периодически обновляемое окно с индикатором выполнения сборки. После выполнения каждого шага в результатах показывается успешность или неуспешность его выполнения. Все выглядит так, как будто сборка работает. Так ли это на самом деле? Метод, который по умолчанию использует Build Forge, чтобы оценить результат - это анализ кода завершения, который операционная система возвращает при выполнении шага. В отношении задач Ant, аналогичных показанной в шаге 2 ниже, коду завершения не всегда можно доверять.

Просматриваем журналы сборки

Нажмите ссылку Build Tomcat.
При помощи полосы прокрутки перейдите в конец текста вывода. Вывод Ant содержит сообщение BUILD FAILED.

Почему же код завершения показывает Build Forge, что шаг был успешно выполнен? В данном случае операционная система получила указание выполнить команду Ant с набором параметров (которые содержатся в файлах build и properties). Если операционная система может найти команду Ant, а команда Ant может найти указанные файлы, то этого достаточно, чтобы получить код завершения, говорящий об успешности выполнения. Данная проблема часто возникает при сборке. Успешность или неуспешность выполнения шага часто приходится определять путем изучения вывода сборки. Поиск нужной информации в длинных файлах журналов - это дорогостоящая и подверженная ошибкам процедура.

Build Forge предоставляет возможность автоматизировать поиск сообщений при помощи фильтров журнала. Создайте фильтр журнала для поиска не слишком загадочного сообщения BUILD FAILED в шаге Ant, примените его к шагу и повторно выполните шаг.

Создаем фильтр журнала

Перейдите в категорию Projects.
Нажмите кнопку Log Filters.
Введите в поле Name Ant filter.
Нажмите кнопку Save.

Определяем шаблон для фильтра

Каждый фильтр может иметь любое число шаблонов. Шаблоны - это регулярные выражения, которые Build Forge применяет к выводу журнала. Чтобы узнать предлагаемые возможности, изучите команды в меню Action.

Очень полезна команда Notify, которую мы в данном учебном руководстве использовать не будем. Прекрасным примером применения Notify в фильтре журнала может быть создание шаблона, который будет искать сообщение об ошибках переполнения диска в процессе выполнения шага сборки, создающего много файлов. Без этой операции уведомления для разработчиков - это пустая трата их времени. Необходимо уведомить об ошибках операторов, чтобы они могли освободить место на диске или указать новое место для записи. Использование команды Notify в фильтрах позволяет отправлять целевые уведомления. Если пользователи получают только те сообщения, которые касаются непосредственно их, то вероятность того, что они примут автоматически рассылаемые электронные сообщения за спам, будет гораздо меньшей.

Введите в поле Pattern BUILD FAILED и убедитесь, что в поле Action выбрано значение Set Fail.
Нажмите кнопку Save.

Примените созданный фильтр к шагу Ant в сборке Tomcat

Перейдите в категорию Projects.
Выберите Tomcat в списке проектов.

Нажмите ссылку Build Tomcat.
Выберите в поле Result значение Ant filter.
Нажмите кнопку Save Step.
Снова запустите проект, нажав кнопку Start Project.
Нажмите кнопку Execute.
Обратите внимание на то, что значение B в секции Tags увеличилось по сравнению с последней сборкой.

Теперь, после запуска сборки, мы получим корректное уведомление о том, что сборка не была выполнена. Изучив записи в журнале для этого шага, вы также увидите, что фильтр журнала выделил совпадения, в значительной степени упростив поиск момента сбоя в длинном журнале.

Теперь нам нужно решить проблему, вызвавшую появление сообщения BUILD FAILED. Изучив вывод журнала, вы увидите сообщения об ошибках компилятора, которые ссылаются на несуществующие пакеты и классы. Проблемы такого типа обычно связаны с отсутствием доступа к библиотекам, от которых зависит сборка. В данном случае библиотеки - это те файлы, которые мы ранее загрузили в каталог c:\usr\share. В описании шага, на котором создавался файл свойств, упоминалась переменная, управляющая этим моментом. Мы не указали значение для этой переменной в группе окружения, ассоциированной с проектом, поэтому Ant не может найти библиотеки. Следующий шаг поможет нам решить проблему.

Добавьте недостающее значение группы окружения

Перейдите в категорию Environments.
Нажмите ссылку tomcat_build_properties.

Введите в поле Name base.path.
Введите в поле Value c:/usr/share.
Нажмите кнопку Save Variable.

Чтобы снова запустить проект, выполните следующие действия.

Перейдите в категорию Projects.
Выберите из списка проектов проект Tomcat.
Нажмите кнопку Start Project.
Нажмите кнопку Execute.

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

Тестируем вывод сборки

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

Файл Tomcat server.xml в каталоге output\build\conf - это как раз тот файл, который нужно изменить. Существует несколько способов (причем один проще другого) сделать это. Build Forge предоставляет несколько удобных методов для выполнения распространенных задач сборки и развертывания. Один из методов - команда .strsub, информацию о которой можно найти в интернет-справке.

Автоматизируем операцию изменения порта Tomcat

Создайте в проекте сразу после шага сборки шаг для изменения номера порта, как показано ниже.

Перейдите в категорию Projects.
Выберите из списка проектов Tomcat.

Нажмите кнопку Add Step.
Введите в поле Name Change port number.
В секции Command введите строку .strsub 8080 %target_port% $BF_ROOT\output\build\conf\server.xml ..
Нажмите кнопку Save Step.

Еще раз выполните проект, последовательно нажав кнопки Start Project и Execute.

В выводе журнала мы увидим результат подстановки.

Тестируем собранные двоичные файлы

Теперь мы готовы запустить Tomcat и проверить, получился ли в результате сборки работоспособный сервер Tomcat.

Откройте окно командной строки.
Перейдите в каталог сборки Builde Forge (команда cd). Каталоги могут быть разными для разных номеров сборки.
В выводе для приведенного выше примера можно увидеть имя каталога в первой строке вывода. cd c:\build\Tomcat\TC_6_BUILD_4\output\build\bin.
Введите команду catalina run

Откройте в браузере URL http://localhost:8081/ и убедитесь, что сервер Tomcat запущен.

Завершаем работу Tomcat

Позднее мы перезапустим сервер Tomcat. Чтобы избежать ошибок на данном этапе, пока остановим Tomcat. Для этого либо закройте окно командной строки, из которой он был запущен, либо нажмите Ctrl+c и подтвердите завершение пакетного задания. Попробуйте обновить страницу http://localhost:8081/ в браузере. Если вы завершили работу Tomcat, то вы увидите сообщение об ошибке. Это именно то, что нужно!

Результаты

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

Мы автоматизировали стадию компиляции и упаковки. При этом была создана иерархия сборок, в которой каждая сборка сохраняется сразу после ее выполнения - это существенное усовершенствование по сравнению с неавтоматизированным процессом.
Мы получили сборку, которую может запустить любой пользователь, обладающий доступом к Build Forge. Для этого не нужно обладать специфическими знаниями Ant, свойств или конфигурационных файлов Tomcat.
Мы настроили сборку на рациональный просмотр журналов, чтобы облегчить процесс определения ее успешности или неуспешности.

ВЫПОЛНЯЕМ РАЗВЕРТЫВАНИЕ TOMCAT ПРИ ПОМОЩИ BUILD FORGE

Автоматизация процесса сборки - это достижение. Рекомендуем вам пойти дальше и автоматизировать процесс развертывания и, если можно, верификации сборки при помощи автоматизированных тестов. В этом разделе мы дополним сборку Tomcat процессом развертывания.

Имитируем развертывание

Для имитации развертывания мы создадим в Build Forge новый объект server, который будет выполнять функции сервера развертывания. Развертывание будет осуществляться в той же физической системе, которая использовалась для сборки, но мы логически разделим эти две среды, чтобы в дальнейшем было легче мигрировать на другой физический сервер. При помощи Build Forge можно достоверно имитировать многосерверную среду.

Чтобы создать каталог развертывания и открыть к нему общий доступ, выполните следующие действия.

В окне командной строки введите команду md c:\deploy.
Затем введите команду net share deploy=c:\deploy /GRANT:Administrator,FULL /UNLIMITED.

Чтобы создать сервер развертывания в Build Forge:

Перейдите в категорию Servers.
Введите deploy_server в поле Name.
Введите в поле Path строку c:\deploy.
Введите в поле Host значение localhost.
В поле Authentication выберите значение localhost auth.
Нажмите кнопку Save.

Тестируем подключение к серверу развертывания:

Выделите в списке серверов deploy_server.
Нажмите кнопку Test Connection.
Убедитесь, что в выводе присутствует сообщение Functional Test: Ok

Создаем объект selector для сервера развертывания:

Перейдите в категорию Selectors.
Введите deploy_selector в поле Name.
Нажмите кнопку Save.

Чтобы добавить переменную селектора:

Введите deploy_server в поле Name.
Нажмите кнопку Save.

Теперь, когда у нас есть сервер, на котором можно выполнить развертывание, и этот сервер ограничен работой в каталоге c:\deploy , можно перейти к созданию шагов для выполнения развертывания. Развертывание обычно включает четыре стадии:

остановка сервера;
удаление старых файлов развертывания;
копирование новых файлов;
перезапуск.

Создаем шаг для остановки Tomcat

Перейдите в категорию Projects.
Выберите из списка проектов Tomcat.

Нажмите кнопку Add Step и введите в поле Name строку Shutdown Tomcat on Deployment Sever .
В поле Directory введите /build.
В поле Path выберите значение Absolute.
Введите в секцию Command команду bin\shutdown.bat.
В поле Selector выберите значение deploy_selector.
В поле On Fail выберите значение Continue.
Нажмите кнопку Save Step.

Создаем шаг для удаления устаревших файлов развертывания

Введите в поле Name Remove old deployment files.
В поле Path выберите значение Absolute.
В секции Command введите команду rd /s /q build.
В поле Selector выберите значение deploy_selector.
В поле On Fail выберите значение Continue.
Нажмите кнопку Save Step.

Создаем шаг для копирования новых файлов на сервер развертывания

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

Введите в поле Name Copy new files to deployment server.
Выберите в поле Path значение Relative.
Введите в секции Command строку xcopy output\build \\localhost\deploy\build /E /Y /I .
Нажмите кнопку Save Step.

Создаем шаг для запуска Tomcat

Введите Startup Tomcat on Deployment Server в поле Name.
В поле Directory введите /build.
В поле Path выберите значение Absolute.
Введите в секции Command команду bin\shutdown.bat.
В поле Selector выберите значение deploy_selector.
В поле On Fail выберите значение Continue.
Нажмите кнопку Save Step.
Командный файл Tomcat startup.bat всегда возвращает операционной системе код ошибки выполнения; это означает, что для данного шага выбрана опция Continue on Fail. Стратегия заключается в том, чтобы продолжить проверку и протестировать, действительно ли сервер будет запущен при выполнении следующего шага.

Тестируем развернутый сервер

На данный момент лучшим передовым методом считается включение в процедуру автоматизированных тестов, позволяющих убедиться в том, что только что собранный и развернутый код готов для передачи тестировщикам. Хороший вариант - использование инструмента типа Rational Functional Tester, пригодного для тестирования Web-приложений. Программа откроет страницу, выполнит переход по нескольким ссылкам, попытается сделать запись об операции в журнале и т. д. В этом учебном руководстве мы не будем касаться таких сложных моментов, и вместо этого выполним быструю проверку на уровне операционной системы, чтобы убедиться, что процесс прослушивает порт 8081 Это будет прекрасным свидетельством того, что только что развернутый сервер Tomcat готов к работе.

Этот тест выполняется при помощи команды netstat и фильтра журнала, который выбирает записи, касающиеся порта 8081.

Создаем фильтр журнала

Нажмите кнопку Log Filters.
Введите в поле Name Tomcat Build Verification.
Нажмите кнопку Save.
Введите в поле Pattern Active Connections.
Выберите в поле Action значение Set Fail.
Нажмите кнопку Save.
Введите в поле Pattern 8081.
Выберите в поле Action значение Clear Fail.
Нажмите кнопку Save.

Этот фильтр действует в два этапа. На первом этапе он констатирует невыполнение шага при наличии в выводе строки Active Connections. На этом он не завершает работу немедленно, а ожидает появления в выводе значения 8081 . Сбои будут определяться в любой ситуации, а успешное выполнение должно регистрироваться только в том случае, если развертывание Tomcat прошло успешно, и он прослушивает порт.

Создаем шаг для тестирования Tomcat

Перейдите в категорию Projects.
Выберите из списка проектов Tomcat.

Нажмите кнопку Add Step.
Введите в поле Name строку Test for service listening on Deployment Server.
В секции Command введите следующую команду:
.sleep 5 netstat -a
В поле Selector выберите значение deploy_selector.
В поле Result выберите значение Tomcat Build Verification.
Нажмите кнопку Save Step.
Шаг ожидания необходим для того, чтобы Tomcat хватило времени на запуск и открытие порта. В противном случае тест будет регистрировать неуспешность выполнения.

Теперь наш список шагов больше похож на реальный проект, чего и следовало ожидать, поскольку мы выполнили сборку и развертывание настоящего Java-проекта.

Снова выполняем проект

Запустите проект как обычно, нажав последовательно кнопки Start Project и Execute.

Можно поставить еще несколько галочек. Общие задачи развертывания выполнены. После успешной сборки Build Forge теперь может остановить сервер, удалить ненужные файлы, скопировать новые файлы и перезапустить сервер развертывания.

НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ

До сих пор мы в достаточной степени контролировали проект, используя Build Forge для управления сборками. Возможно, вы думали и о других способах, которые могли бы улучшить или дополнить описанные функции. Почему бы не включить номер сборки Build Forge в HTML-код домашней страницы при помощи команды .strsub dot и встроенных переменных? Вы можете еще долго заниматься настройкой и добиться фантастических результатов в автоматизации функций.

Реальный пример использования сборки Tomcat, который мы создали, предназначен для сборки Tomcat из самой последней версии кода при любом внесении разработчиком изменений в базовый код Tomcat. Вслед за этим можно взять внутренний проект сервлета, развернуть его на только что созданном и развернутом сервере Tomcat и выполнить тесты, чтобы посмотреть, все ли в порядке. Чтобы описанное тестирование интеграции между Tomcat и вашим кодом выполнялось непрерывно (непрерывная интеграция), необходимо:

Задать частоту проверки проекта Tomcat на наличие обновлений.
Проверить сервер Tomcat, чтобы выяснить, были ли зафиксированы обновления с момента последней сборки.
Если обновления были, получить самую последнюю версию кода.
Запустить процесс автоматизированной сборки и развертывания.

Наша цель - автоматизировать все этапы этого процесса. Как и при автоматизации сборки, мы начнем выполнять процесс вручную, найдем способы преодоления различных препятствий и, после того как процесс будет успешно выполняться из командной строки, используем Build Forge для настройки автоматизации.

Запускаем процесс выгрузки из репозитория Subversion

В окне командной строки введите следующую команду:

md c:\temp\svn_tomcat
cd c:\temp\svn_tomcat
svn checkout http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/

Клиентский компонент системы Subversion установит соединение с репозиторием Tomcat Subversion и начнет копирование самой последней версии кода в каталог c:\temp\svn_tomcat.

Получаем обновленные зависимые файлы для Tomcat

После того как последняя версия кода загружена, необходимо получить обновленные библиотеки для выполнения компиляции. В командной строке введите команду:

cd trunk
ant download

Запускаем сборку Tomcat из командной строки

Используя свойства по умолчанию, выполните сборку Tomcat в каталог c:\temp\svn_tomcat\trunk посредством ввода в окне командной строки команды:

ant

Запускаем сборку Tomcat из Build Forge

В процессе изучения данного учебного руководства разработчики Tomcat в последней версии кода Subversion изменили каталог по умолчанию для библиотек, используемых в этом процессе сборки, с c:\usr\share в 6.0.14 source на c:\usr\share\java. Чтобы изменить параметры сборки для изменений Tomcat:

Перейдите в категорию Environments.
Нажмите ссылку tomcat_build_properties.

Выберите base.path в списке переменных.
Введите в поле Value c:/usr/share/java.
Нажмите кнопку Save Variable.

Изменяем файл build.xml, на который ссылается проект Tomcat:

Перейдите в категорию Projects.
Выберите из списка проектов Tomcat.

Выберите в списке шагов шаг Build Tomcat.
Измените команду на:
ant -propertyfile temp.properties -buildfile C:\temp\svn_tomcat\trunk\build.xml
Нажмите кнопку Save Step.

Снова выполняем проект

Снова выполните проект с самой последней версией исходного кода, нажав последовательно кнопки Start Project > Execute.

Мы сделали необходимые изменения, позволяющие нам получать последнюю версию кода для сборки в рабочей группе Tomcat. Мы использовали инструмент Subversion для получения самой последней версии кода вручную, и теперь мы готовы к настройке Build Forge на непрерывное получение самой последней версии кода.

Build Forge использует адаптеры для взаимодействия с такими системами управления версиями как Subversion, IBM® Rational ClearCase, CVS и т. п. Адаптеры пишутся на гибком языке программирования на базе XML, который специально предназначен для взаимодействия с API командной строки. Функция адаптера заключается в выполнении команд, необходимых для непрерывной интеграции, анализе вывода и принятии однозначного решения по поводу запуска сборки. Адаптер хранит необходимую информацию, например, номер версии в репозитории с момента последней успешной сборки, в переменных группы окружения. Кроме того, он хранит информацию об идентификационных данных разработчика, зафиксировавшего изменения в базовом коде, и изменения кода; вся эта информация фиксируется в отчетах сборки или используется в уведомлениях по электронной почте.

Чтобы настроить непрерывную интеграцию, необходимо создать несколько перечисленных ниже объектов Build Forge.

Объект Build Forge	Функция
Adapter environment group (Группа окружения адаптера)	Содержит специфические переменные для подключения к репозиторию системы Subversion и информации о текущей версии.
Adaptor (Адаптер)	Содержит команды командной строки, которые необходимо выполнить по отношению к репозиторию Subversion .
Связка адаптера (Adaptor link)	Объединяет адаптер, проект и группу окружения
Расписание (Schedule)	Устанавливает временные интервалы для проверки репозитория Tomcat Subversion на наличие изменений.

Создаем группу окружения адаптера

Нам нужно создать пустую группу окружения, которая будет заполнена системой Build Forge после создания адаптера.

Перейдите в категорию Environments.
Введите tomcat_svn_env в поле Name.
Нажмите кнопку Save Environment.

Пока не нужно добавлять переменные в эту группу окружения.

Разрешаем использование шаблонов адаптеров для системы Subversion

Чтобы гарантировать загрузку шаблонов для системы Subversion через Build Forge, выполните следующие действия:

Перейдите в категорию Administration.
Перейдите к элементу System.
Введите в поле Filter reset interface.
Нажмите кнопку Filter.
В списке свойств системы System properties выберите Reset Interface Templates.
Выберите значение Yes в поле Reset Interface Templates.
Нажмите кнопку Save.

Создаем адаптер

Перейдите в категорию Projects.
Откройте страницу Adaptors.
Введите tomcat_svn_adaptor в поле Name.
Выберите значение SubversionByRev в поле Template.
Нажмите кнопку Save Adaptor.

Создаем связку адаптера

Чтобы связать воедино проект, группу окружения адаптера и сам адаптер, мы создаем связку адаптера Adaptor Link.

Откройте страницу Adaptor Links.
Выберите значение tomcat_svn_adaptor в поле Adaptor.
Выберите Tomcat в поле Project.
Выберите значение tomcat_svn_env в поле Environment.
Выберите значение yes в поле Populate Env.
Нажмите кнопку Save.

Чтобы проверить сгенерированные переменные группы окружения адаптера, выполните следующие действия.

Перейдите в категорию Environments.
Выберите ссылку tomcat_svn_env из списка групп окружения.

При сохранении связки адаптера были созданы следующие переменные и значения.

Для синхронизации с репозиторием Tomcat Subversion значения по умолчанию необходимо изменить. Необходимо указать номер последней версии (SVN_LAST_REV), совпадающий с редакцией, которая была получена ранее. Это значение будет использоваться для определения более поздней версии, доступной для загрузки. Если оставить значение 0, то первая сборка начнет загрузку всех изменений кода, которые были зафиксированы в репозитории. Нам нужны только отличия между двумя сборками, а не вся предыстория, поэтому необходимо определить номер редакции, которая была загружена последней, и вместо 0 использовать это значение.

Получаем номер редакции Subversion для текущей версии кода

В командной строке введите команду:

cd c:\temp\svn_tomcat\trunk
svn info

Просмотрите результаты выполнения команды svn info и запишите значение для Last Changed Rev.

Для целей тестирования укажите число редакций, в которых будут выбраны изменения, но не больше 50, в противном случае выполнение команды svn займет слишком много времени. Поэкспериментируйте со значениями в следующей команде, заменив значение Last Changed Rev на 590541, а значение, начинающееся с числа, приблизительно на 500 меньше этого значения, на 59000.

Эта команда выполнит запрос к репозиторию Tomcat Subversion на выборку записей в журнале, относящихся к изменениям, имевшим место между указанными номерами редакций. Если командная строка показывает всего один журнал, попробуйте выполнить команду снова с меньшими значениями, убывающими на 100 при каждом выполнении команды, пока не получите нужный результат. Запишите значение, потому что позднее его придется вводить в переменной группы окружения адаптера SVN_LAST_REV.

Чтобы записать значения в переменные группы окружения, выполните следующие действия:

Выберите в списке переменных окружения переменную SVN_REPOSITORY.
Введите http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ в поле Value.
Нажмите кнопку Save Variable.

Повторите процедуру для перечисленных ниже переменных, а для остальных переменных сохраните значения по умолчанию.

Переменная окружения	Значения
SVN_REPOSITORY	http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
SVN_CLIENT	build_server
SVN_LAST_REV	[use SVN_LAST_REV calculated earlier]

Запускаем адаптер

После вызова адаптер получает доступ к переменным окружения адаптера, которые применяются в качестве параметров для команд системы Subversion. Адаптер выполнит три команды:

команда svn info возвратит номер самой последней версии для репозитория;
после этого команда svn log использует номер последней редакции и значение переменной окружения адаптера SVN_LAST_REV для получения журналов изменений в репозитории, которые были зафиксированы с момента последней сборки;
команда svn diff запишет в спецификацию материалов (Bill of Materials) Build Forge изменения кода для сборки.

Если команда svn log не обнаружит изменений, то сборка не будет выполнена. Если изменения будут обнаружены, то сборка будет выполнена, а адаптер обновит переменные SVN_LAST_REV в переменных окружения адаптера. После этого адаптер может отправить разработчикам сообщения по электронной почте, чтобы информировать их о запуске сборки и о ее успешности или неуспешности.

Адаптеры исходного кода, аналогичные тому, который мы настроили, предназначены для выполнения по расписанию. Однако при создании и отладке адаптеров ожидание запланированного времени означает непроизводительную потерю времени. Чтобы запустить адаптер вручную, необходимо изменить системные параметры.

Перейдите в категорию Administration.
Откройте страницу System.
Введите в поле Filter значение link.
Нажмите кнопку Filter.
Выберите Yes в поле Link Manual Jobs.
Нажмите кнопку Save.

Чтобы запустить адаптер, выполните следующие действия:

Перейдите в категорию Projects.
Выберите из списка проектов Tomcat.
Нажмите кнопку Start Project.
На вкладке Job Details теперь отображается флажок Run Link. Это результат разрешения Link Manual Jobs на странице System Administration.
Нажмите кнопку Execute.
Первым в списке отображается адаптер tomcat_svn_adaptor, который показывает выполнение связки. Содержимое tomcat_svn_env (значения для SVN_LAST_REV и SVN_LAST_DATE) было обновлено. Если нужно еще раз выполнить этот тест, важно задать для SVN_LAST_REV предыдущее значение (в нашем примере 590000), иначе адаптер не обнаружит никаких изменений, если он запущен, а проект не будет выполнен.

Изучаем спецификацию материалов Bill of Materials

В процессе сборки адаптер записывает информацию в спецификацию материалов Bill of Materials. Спецификация материалов Bill of Materials представляет собой документ аудита, который содержит журналы сборки и изменения, относящиеся к сборке, и может служить основой для отчета сборки. Чтобы получить доступ к спецификации материалов Bill of Materials по завершении сборки, выполните следующие действия:

Перейдите в категорию Bill of Materials.
Разверните заголовки секций.

Создаем расписание

Адаптер может проверять наличие изменений и запускать сборку при их обнаружении. Теперь нам нужно настроить расписание его запуска. Расписание должно отражать ваше решение в отношении частоты выполнения проверок. Чем чаще в базовый код вносятся изменения, тем чаще необходимо выполнять сборки.

Минимальный интервал между сборками должен быть равным средней продолжительности сборки плюс время на буферизацию, если только у вас нет специального кластера серверов сборки для выполнения сборок. Для нашего примера укажите в расписании время запуска через каждые 15 минут. Значения для периодичности запуска расписания должны быть знакомы специалистам, которым приходилось конфигурировать задания для демона cron на серверах UNIX. В противном случае поищите примеры в интернет-справке по Build Forge.

Перейдите в категорию Schedules.
Введите Tomcat Continuous Integration в поле Description.
Выберите Tomcat в поле Project.
Введите в поле Minutes значение */15.
Нажмите кнопку Save Schedule.

Можете раскрасить зеленым цветом ячейку в столбце "Автоматизированные" для еще одной задачи.

Обновляем исходный код Tomcat в процессе сборки

В столбце неавтоматизированных осталась задача "Получить самую последнюю версию исходного кода". Хотя адаптер проверяет код на наличие изменений и записывает отличающиеся фрагменты кода, на самом деле он не обновляет код, который собирает и развертывает Build Forge. Чтобы исправить это, необходимо добавить еще один шаг.

Запустите адаптер.
Перейдите в категорию Projects.
Выберите из списка проектов Tomcat.

Нажмите кнопку edit.
В раскрывающемся меню Button Menu Options выберите команду Insert New Step.

Введите Get Latest Tomcat Source в поле Name.
В поле Path выберите значение Absolute.
В секции Command введите следующую строку:
cd c:\tomcat_source\trunk svn update --non-interactive
Нажмите кнопку Save Step.

Теперь список шагов включает новый шаг перед шагом Build Tomcat.

Конфигурируем сервер для отправки уведомлений по электронной почте

Для выполнения этого шага нам необходим IP-адрес SMTP-сервера, через который консоль управления Build Forge Management Console сможет отправлять почту.

Перейдите в категорию Administration.
Откройте страницу System.
Введите в поле Filter smtp.
Нажмите кнопку Filter.
Выберите SMTP Server из списка свойств системы.
В поле SMTP Server введите действующее имя smtp-сервера или IP-адрес.
Нажмите кнопку Save.

Настраиваем адрес электронной почты для учетной записи пользователя

В категории Administration откройте страницу Users.
В списке пользователей выберите учетную запись Root User.
Введите свой адрес электронной почты.
Нажмите кнопку Save.

Настраиваем уведомления

Перейдите в категорию Projects.
Нажмите кнопку edit рядом с только что созданным проектом Tomcat.
Выберите значение Build Engineer в полях Pass Notify и Fail Notify.
Нажмите кнопку Save Project.

Прекрасная работа - мы закончили автоматизацию задач.

Build Forge проверяет репозиторий Tomcat Subversion по сети Интернет каждые 15 минут на наличие изменений в коде. Если изменения будут обнаружены, система обновит наш локальный код и запустит сборку. По завершении сборки Build Forge изменит конфигурационный файл Tomcat, чтобы подготовить его для использования в среде развертывания. После этого Build Forge передаст только что скомпилированный код на сервер развертывания, выполнит перезагрузку экземпляра сервера Tomcat и выполнит тест.

ЗАКЛЮЧЕНИЕ

В этом учебном руководстве мы шаг за за шагом выполнили сборку реального проекта. Теперь вы знаете, как выполнить сборку Tomcat с нуля, автоматизировать сборку при помощи Rational Build Forge, развернуть сервер Tomcat, изменить параметры развертывания, получить актуальную версию кода Tomcat из репозитория и настроить Build Forge на выполнение регулярных проверок кода на наличие изменений с последующим запуском сборок. Неплохо для двух дней работы.

Ссылки по теме

Совершенствуем процесс сборки при помощи IBM Rational Build Forge : Часть1. Создаем среду непрерывной сборки и интеграции

Совершенствуем процесс сборки при помощи IBM Rational Build Forge: Часть 2. Автоматизируем процесс сборки для реального проекта Tomcat