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

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

Введение

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

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

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

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

В этом примере механизм 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, используемый в этом примере.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.
В этом примере цель 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.

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

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

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

Загрузка