Автоматизация непрерывной сборки программного обеспечения в Rational Team Concert может выполняться по расписанию или по требованию. Такэхико Амано описывает способ предварительной проверки перед запуском процесса фактической сборки для снижения риска ошибки в процессе сборки с использованием механизма Apache Ant. Он приводит пример определения рабочих элементов, которые должны быть включены в текущую сборку, проверки состояния каждого рабочего элемента и последующего запуска процесса сборки.
Выполнение процесса сборки по определенному событию, такого как ночная сборка или сборка по требованию, ― обычная практика разработки программного обеспечения. Процесс сборки крупного пакета программного обеспечения может занять несколько часов или даже дней. Часто в процессе сборки происходит сбой. С точки зрения практики гибкого управления это огромная потеря. Особенно когда сборка выполняется в облачной инфраструктуре, где плата начисляется по фактическому использованию ресурсов процессора.
Предварительная проверка уменьшает риск ошибки при сборке. В некоторых случаях в процессе сборки требуется утверждение. Например, при создании выпускной сборки, так как если она содержит нежелательные изменения, то затраты на восстановление после выпуска, как правило, очень значительны и становятся еще одной неожиданной статьей расходов. Поэтому перед запуском основного процесса сборки полезно выполнить предварительную проверку.
Пример сборки в Rational Team Concert
На рисунке 1 приведен пример установки, используемой для этой статьи, с сервером IBM® Rational Team Concert и механизмом сборки Jazz (jbe-engine). Сервер запрашивает сборку посредством определения сборки Apache Ant (ant-build).
Рисунок 1. Пример установки для сборки, используемой в этой статье
В этом примере механизм 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 показывает, что сборка не удалась
В этой статье рассматривается цель 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
Этот код просто проверяет, утвержден ли указанный рабочий элемент. Если его статус не 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 |