Предварительная проверка перед сборкой для снижения риска ошибки

Источник: IBM

Автоматизация непрерывной сборки программного обеспечения в Rational Team Concert может выполняться по расписанию или по требованию. Такэхико Амано описывает способ предварительной проверки перед запуском процесса фактической сборки для снижения риска ошибки в процессе сборки с использованием механизма Apache Ant. Он приводит пример определения рабочих элементов, которые должны быть включены в текущую сборку, проверки состояния каждого рабочего элемента и последующего запуска процесса сборки.

Введение

Выполнение процесса сборки по определенному событию, такого как ночная сборка или сборка по требованию, ― обычная практика разработки программного обеспечения. Процесс сборки крупного пакета программного обеспечения может занять несколько часов или даже дней. Часто в процессе сборки происходит сбой. С точки зрения практики гибкого управления это огромная потеря. Особенно когда сборка выполняется в облачной инфраструктуре, где плата начисляется по фактическому использованию ресурсов процессора.

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

Пример сборки в Rational Team Concert

На рисунке 1 приведен пример установки, используемой для этой статьи, с сервером IBM® Rational Team Concert и механизмом сборки Jazz (jbe-engine). Сервер запрашивает сборку посредством определения сборки Apache Ant (ant-build).

Рисунок 1. Пример установки для сборки, используемой в этой статье
Пример процесса сборки в Rational Team Concert

В этом примере механизм Jazz Build Engine работает на сервере Microsoft Windows. Механизм сборки определяется как jbe-engine. Сборка определяется как ant-build и использует jbe-engine для запуска процесса сборки Apache Ant. В этом примере build.xml, используемый в процессе сборки, не находится под управлением исходными текстами, чтобы сделать объяснение как можно проще.

Выполнение предварительной проверки сборки Ant в Rational Team Concert

Rational Team Concert поддерживает различные механизмы сборки. Эта статья иллюстрирует использование процесса сборки Ant, но этот пример применим и к большинству других поддерживаемых процессов сборки.

Сборка Ant содержит механизм зависимостей. Например, класс .java должен быть создан до создания файла .jar. Для этого Java компилирует файл .java, создавая файл .class. В предлагаемой статье для предварительной проверки используется этот механизм зависимостей. Листинг 1 иллюстрирует основной конструктивный блок файла build.xml, используемый в этом примере.

Листинг 1. Конструктивный блок файла Build.xml
<?xml version="1.0" encoding="UTF-8"?>
<project name="buildtest" default="main">
<target name="main" depends="pre-condition" description="">
<echo>
Работа с основной сборкой
</echo>
</target>
<target name="pre-condition">
<echo>
Подготовка к сборке
</echo>
</target>
</project>

Перед вводом цели main оценивается и выполняется цель pre-condition. Если проверка проходит успешно, запускается основная цель. В листинге 2 приведен результат из журнала событий выполнения этого кода build.xml в механизме сборки Rational Team Concert.

Листинг 2. Результат сборки файла sample.build.xml, приведенного в листинге 1
Buildfile: C:\BUILDS\build.xml
pre-condition:
[echo]
[echo] Предварительная проверка
[echo]
main:
[echo]
[echo] Основная сборка
[echo]

BUILD SUCCESSFUL

Чтобы проиллюстрировать, как это работает, добавим задачу <fail/>, как показано в листинге 3. Она указывает Ant на ошибку.

Листинг 3. Пример файла build.xml, выдающего ошибку при предварительной проверке
<?xml version="1.0" encoding="UTF-8"?>
<project name="
Работа с основной сборкой
</echo>
</target>
<target name="pre-condition">
<echo>
Precondition for build
</echo>
<fail/>
</target>
</project>

Оператор echo в области main этого примера распечатан не будет. Кроме того, красный значок статуса сборки в клиенте Rational Team Concert (см. рисунок 2) указывает на то, что сборка не удалось.

Рисунок 2. Представление Builds в Rational Team Concert показывает, что сборка не удалась
Красный кружок с белым значком X указывает на состояние ошибки при сборке

В этой статье рассматривается цель precondition на нескольких (надеюсь, полезных) примерах, непосредственно связанных с артефактами Rational Team Concert.

Пример 1. Проверка статуса утверждения рабочего элемента

В этом примере используется код Java. Весь исходный код прилагается к этой статье (см. раздел Загрузки). Сценарий этого примера таков:

проверить, что статус указанного рабочего элемента Approved (утвержден).

Java-код выполняется с помощью клиентской Java-библиотеки Rational Team Concert. Пример кода принимает пять аргументов (упрощенная командная строка):

java CheckWorkItemState < repository > < project-name > < userid > < password > < work item-id >

Например, предположим, что есть рабочий элемент с номером 123, и для него требуется статус Approved. Если статус рабочего элемента Approved, команда возвращает status 0.

> java -Djava.ext.dirs=%JAVA_HOME%/lib/ext;C:/BUILDS/RTC-ClientLib -cp .
CheckWorkItemState https://localhost:9443/ccm RTC Project jazzadmin jazzadmin 123

В примере строка о статусе Approved жестко запрограммирована. Строку статуса можно указать в параметре сборки, а затем передать в процесс сборки.

Эта команда вызывается из сценария сборки Ant, допускающего сборку в Rational Team Concert. Когда вызывается сценарий сборки, в процесс передаются несколько параметров. Например, параметр <repository> передается как ${repositoryAddress}. Полный список параметров приведен в информационном центре Rational Team Concert. Некоторые параметры должны быть заданы в определении сборки. Чтобы пример кода можно было выполнить, в определении сборки должны быть заданы следующие параметры, приведенные в таблице 1.

Таблица 1. Параметры сборки, используемые в этом примере

Имя

Пример значения

Описание

buildFolder C:\BUILDS Имя папки для инструментов сборки. Она должна содержать клиентскую Java-библиотеку Rational Team Concert
projectName TEST Имя области проекта.
workItemID   Идентификатор рабочего элемента. Остается пустым.

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

Листинг 4. Фрагмент файла build.xml для цели precondition
<java classname="CheckWorkItemState" fork="yes" failonerror="true">
<classpath>
<pathelement path="${buildFolder}/commands" />
</classpath> <jvmarg value=
"-Djava.ext.dirs=${java.home}/lib/ext;${buildFolder}/RTC-ClientLib" />
<arg line="${repositoryAddress}"/>
<arg line="${userId}" />
<arg line="${password}" />
<arg line="${projectName}" />
<arg line="${workItemId}" />
</java>

Весь файл build.xml, используемый в этом примере, прилагается к статье (см. раздел Загрузки). На рисунке 3 показано диалоговое окно Request Build. В этом примере идентификатор рабочего элемента задается в качестве параметра сборки. В примере передается ID = 116.

Рисунок 3. Диалоговое окно с указанием рабочего элемента сборки 116
В качестве значения указано 116

Этот код просто проверяет, утвержден ли указанный рабочий элемент. Если его статус не Approved, процесс сборки останавливается. Результат A в листинге 5 соответствует результату сборки при статусе рабочего элемента New. Как видно, сборка прерывается.

Листинг 5. Результат A, когда состояние рабочего элемента отлично от Approved
pre-condition:
[echo]
[echo] Проверка статуса рабочего элемента...
[echo]
[java] Статус рабочего элемента: New.
[java] Сборка прерывается

BUILD FAILED
C:\BUILDS\build.xml:31: Java returned: 1

При переходе рабочего элемента в состояние Approved запускается цель main (результат B, листинг 6). Результат B показывает, что когда состояние указанного рабочего элемента Approved, цель precondition достигается успешно и запускается цель main. Статус сборки принимает значение BUILD SUCCESSFUL (успешная сборка).

Листинг 6. Результат B при статусе рабочего элемента Approved
pre-condition:
[echo]
[echo] Проверка статуса рабочего элемента ...
[echo]
[java] Статус рабочего элемента: Approved.
[java] Начинается сборка

main:
[echo]
[echo] Начинается сборка Main ...
[echo]

Примечание.
В этом примере цель main всегда выполняется успешно. В реальной ситуации это зависит от различных условий.

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

Пример 2. Выполнение запроса и проверка состояния рабочих элементов

Процесс сборки Rational Team Concert Ant для использования Rational Team Concert SCM (система управления конфигурацией ПО) можно настроить на выполнение команд accept и load. Команда accep t означает, что рабочая область настроена на использование последних исходных кодов в потоке. Команда load означает загрузку содержимого рабочей области в указанный каталог определения сборки. В зависимости от конфигурации процесса с рабочим элементом, таким как Task, Defect или Enhancement, может быть связан набор изменений.

В Rational Team Concert есть функция personal build, которая позволяет проверить, отвечают ли изменения кода некоторому набору критериев. Примеры критериев должны пройти модульные тесты для проверки разрешения дефектов и т.п. Лучше всего выполнить сборку personal build. Затем разработчик обычно изменяет статус рабочих элементов, связанных с наборами изменений, на Resolved (разрешено) и выпускает набор изменений в поток. Однако иногда разработчик может забыть изменить статус рабочих элементов.

В других случаях разработчики могут случайно выпустить коды без тестирования, так что рабочий элемент останется в состоянии In Progress или даже New. Этот недосмотр может привести к ошибке сборки, поскольку коды не проверены.

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

Для перечисления всех рабочих элементов, включаемых в сборку, можно использовать команду scm compare. Она выводит список рабочих элементов, включаемых в сборку (параметр -I w). Операция Accept принимает наборы изменений из потока. Например, предположим, что поток с именем MAIN является целевым потоком операции Deliver, а BUILD - это рабочая область выпускной сборки. Сравним рабочую область сборки (BUILD) с потоком (MAIN), как показано в листинге 7.

Листинг 7. Список рабочих элементов, которые будут включены в сборку
>scm compare -I w workspace BUILD stream MAIN -u jazzadmin -P jazzadmin
Work Item 19: Это задача
Work Item 26: Это еще одна задача

Этот список показывает, что в новую сборку должны быть включены рабочие элементы с номерами 19 и 26. Чтобы получить только номера рабочих элементов нужно проанализировать результат выполнения команды scm compare. Воспользовавшись инструментом регулярных выражений, пробелами в качестве разделителей, и ликвидировав ':', можно получить номера рабочих элементов (см. пример сценария Perl в листинге 8).

Листинг 8. Пример кода Perl для получения номеров рабочих элементов
while (<> ) {
@wi_info = split(/ /, $_);
chop($wi_info[2]);
print $wi_info[2], "\n";
}

Расширив код примера 1, легко проверить, одинаков ли статус этих рабочих элементов. Код можно дополнить и для циклического перебора всех рабочих элементов.

Примечание.
Пример кода не объясняется, чтобы читатели могли реализовать его и самостоятельно увидеть результаты.

Загрузка

Описание

Имя

Размер

Метод загрузки

Исходный код для этой статьи reduce-risk-build-failure.zip 3 KБ HTTP 

Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=32913