+7 (495) 229-0436 | shopadmin@itshop.ru | 119334, г. Москва, ул. Бардина, д. 4, корп. 3 |
|
|
Предварительная проверка перед сборкой для снижения риска ошибки24.04.2013 12:41
Автоматизация непрерывной сборки программного обеспечения в 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
Перед вводом цели main оценивается и выполняется цель pre-condition. Если проверка проходит успешно, запускается основная цель. В листинге 2 приведен результат из журнала событий выполнения этого кода build.xml в механизме сборки Rational Team Concert. Листинг 2. Результат сборки файла sample.build.xml, приведенного в листинге 1
Чтобы проиллюстрировать, как это работает, добавим задачу <fail/>, как показано в листинге 3. Она указывает Ant на ошибку. Листинг 3. Пример файла build.xml, выдающего ошибку при предварительной проверке
Оператор echo в области main этого примера распечатан не будет. Кроме того, красный значок статуса сборки в клиенте Rational Team Concert (см. рисунок 2) указывает на то, что сборка не удалось. Рисунок 2. Представление Builds в Rational Team Concert показывает, что сборка не удаласьВ этой статье рассматривается цель 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. Таблица 1. Параметры сборки, используемые в этом примере
В параметре сборки в целях автоматизации должен быть указан номер рабочего элемента, как в этом примере или другим способом. Цель precondition можно реализовать так, как показано в листинге 4. Листинг 4. Фрагмент файла build.xml для цели precondition
Весь файл build.xml, используемый в этом примере, прилагается к статье (см. раздел Загрузки). На рисунке 3 показано диалоговое окно Request Build. В этом примере идентификатор рабочего элемента задается в качестве параметра сборки. В примере передается ID = 116. Рисунок 3. Диалоговое окно с указанием рабочего элемента сборки 116Этот код просто проверяет, утвержден ли указанный рабочий элемент. Если его статус не Approved, процесс сборки останавливается. Результат A в листинге 5 соответствует результату сборки при статусе рабочего элемента New. Как видно, сборка прерывается. Листинг 5. Результат A, когда состояние рабочего элемента отлично от Approved
При переходе рабочего элемента в состояние Approved запускается цель main (результат B, листинг 6). Результат B показывает, что когда состояние указанного рабочего элемента Approved, цель precondition достигается успешно и запускается цель main. Статус сборки принимает значение BUILD SUCCESSFUL (успешная сборка). Листинг 6. Результат B при статусе рабочего элемента Approved
Примечание. Приведенный пример можно использовать во многих ситуациях. Например, релиз-инженеру может потребоваться управлять сборкой по состоянию рабочего элемента. Простейший случай использования этого примера для выпускной сборки ― это когда перед запуском процесса выпускной сборки требуется процесс строгого утверждения. Релиз-инженер должен убедиться, что хозяин продукта проверил содержание сборки и утвердил ее. Пример 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. Список рабочих элементов, которые будут включены в сборку
Этот список показывает, что в новую сборку должны быть включены рабочие элементы с номерами 19 и 26. Чтобы получить только номера рабочих элементов нужно проанализировать результат выполнения команды scm compare. Воспользовавшись инструментом регулярных выражений, пробелами в качестве разделителей, и ликвидировав ':', можно получить номера рабочих элементов (см. пример сценария Perl в листинге 8). Листинг 8. Пример кода Perl для получения номеров рабочих элементов
Расширив код примера 1, легко проверить, одинаков ли статус этих рабочих элементов. Код можно дополнить и для циклического перебора всех рабочих элементов. Примечание.
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
О нас |
Интернет-магазин ITShop.ru предлагает широкий спектр услуг информационных технологий и ПО.
На протяжении многих лет интернет-магазин предлагает товары и услуги, ориентированные на бизнес-пользователей и специалистов по информационным технологиям. Хорошие отзывы постоянных клиентов и высокий уровень специалистов позволяет получить наивысший результат при совместной работе. В нашем магазине вы можете приобрести лицензионное ПО выбрав необходимое из широкого спектра и ассортимента по самым доступным ценам. Наши менеджеры любезно помогут определиться с выбором ПО, которое необходимо именно вам. Также мы проводим учебные курсы. Мы приглашаем к сотрудничеству учебные центры, организаторов семинаров и бизнес-тренингов, преподавателей. Сфера сотрудничества - продвижение бизнес-тренингов и курсов обучения по информационным технологиям.
|
119334, г. Москва, ул. Бардина, д. 4, корп. 3 +7 (495) 229-0436 shopadmin@itshop.ru |
|
© ООО "Interface Ltd." Продаем программное обеспечение с 1990 года |