Содержание


Непрерывная поставка с помощью Rational Team Concert и UrbanCode Deploy

Часть 2. Расширение процесса сборки

Comments

Серия контента:

Этот контент является частью # из серии # статей: Непрерывная поставка с помощью Rational Team Concert и UrbanCode Deploy

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Непрерывная поставка с помощью Rational Team Concert и UrbanCode Deploy

Следите за выходом новых статей этой серии.

В данной серии статей представлены два механизма интеграции IBM Rational Team Concert™ и IBM® UrbanCode Deploy для создания процесса непрерывной поставки. Первый подход, рассмотренный в первой части серии статей, – это легко настраиваемая упакованная готовая реализация. Второй подход, представленный во второй и в третьей частях, использует расширения Ant-файла build.xml.

Примечание.
Использование Ant-сценариев не ограничивает вас только сборкой Java-приложений. Пользователи Rational Team Concert используют Ant и расширения Rational Team Concert для сборки приложений, написанных и на других языках программирования, например C и ADA.

Пример приложения

В качестве примера приложения используется проект JKE Banking, поставляемый с Rational Team Concert. Используя его, можно быстро создать код приложения, а затем выполнить указанные изменения для создания готового решения. Вы также можете расширить свой собственный файл build.xml дополнениями, включенными в загруженный файл.

Примечание.
Не рекомендуется создавать пример приложения в производственной среде Rational Team Concert, поскольку при этом создается несколько пользователей, что нежелательно в рабочей системе. Создайте пример проекта на тестовом сервере Rational Team Concert.

Определение сборки

Определение сборки содержится в примере проекта JKE Banking (jke.dev). В данной статье используется определение сборки jke.dev.build_and_deploy. Необходимые изменения определения сборки описываются в приведенных ниже разделах.

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

Файл build.xml

Файл build.xml представляет собой текстовый файл с Ant-инструкциями по выполнению операций процесса сборки. В данном примере он содержит Ant-инструкции для таких операций, как:

  1. Сборка jar-файла.
  2. Сборка war-файла.
  3. Архивирование war-файла в zip-файл.

Затем полученный zip-файл сохраняется как артефакт сборки в записи сборки Rational Team Concert. Log-файл всех операций, выполненных Ant, также сохраняется как артефакт сборки. В zip-файл включается также оригинальный файл build.xml под именем build-Original.xml.

Расширения сборки для непрерывной поставки

Этап 1. Безопасность сборки

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

В стандартном файле build.xml, поставляемом Rational Team Concert с примером проекта JKE banking, содержатся данные о пароле и идентификаторе пользователя процесса сборки. Они представлены в виде свойств и показаны в листинге 1.

Листинг 1. Пароль и идентификатор пользователя
<property name="userId" value="build" /> 
<property name="password" value="build" />

Многие пользователи систем сборки и автоматизации не хотят раскрывать свой пароль в файле build.xml. Для таких пользователей код из листинга 1 можно заменить ссылкой на файл, содержащий зашифрованный пароль (см. листинг 2).

Листинг 2. Зашифрованный пароль
<property name="userId" value="build" />    <property name="passwordFile" 
value="${basedir}/EncryptedBuildUserPassword.txt"/>

Файл с зашифрованным паролем хранится в том же каталоге, что и файл build.xml. В файле build.xml на него ссылается переменная ${basedir}. Учитывая, что файл build.xml находится на два уровня ниже каталога с контентом, загружаемым процессом сборки в Rational Team Concert (см. рисунок 1), полезно хранить переменную, определяющую корневой (root) каталог: <property name="loadDir" value="${basedir}/../.." />.

Свойство loadDir можно использовать как базовую точку для ссылок на любой файл загружаемого контента, управляемого процессом сборки в Rational Team Concert.

Рисунок 1. Файл build.xml в структуре каталогов проекта
Рисунок 1. Файл build.xml в структуре каталогов проекта
Рисунок 1. Файл build.xml в структуре каталогов проекта

Зашифрованный пароль создается исполняемой программой JBE, расположенной в каталоге [местоположение сборки в Rational Team Concert] > buildsystem > buildengine > eclipse. В каталоге buildsystem находится файл readme. В этом файле приведена подробная информация о том, как создать пароль при помощи программы JBE.

Завершая настройку системы безопасности, замените все ссылки на пароль ссылкой на файл пароля. Вместо password="${password}" укажите passwordFile="${passwordFile}".

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

Добавьте код листинга 3 в файл build.xml после определений свойств, указывающих другие целевые каталоги.

Листинг 3. Свойства, добавляемые в файл build.xml
<property name="destdir.war" value="${loadDir}/build/war" />
<property name="workingDir" value="${basedir}" />
<property name="target.war" value="jke.war" />

Ant-задания расширения сборки из Rational Team Conce

Для использования Ant-заданий, поставляемых с Rational Team Concert, необходимо выполнить два действия. Первое действие – включить местоположение заданий Jazz Build Toolkit в путь к Ant-библиотеке. Для этого установите флажок Include the Jazz build toolkit tasks on the Ant library path (см. рисунок 2). Этот флажок находится на вкладке Ant определения сборки в Rational Team Concert.

Рисунок 2. Ссылка на Jazz Build Toolkit в определении сборки
Рисунок 2. Ссылка на Jazz Build Toolkit в определении сборки
Рисунок 2. Ссылка на Jazz Build Toolkit в определении сборки

Второе действие – добавить определение задания в Ant-файл build.xml. Пример определения задания для запуска процесса сборки приведен в листинге 4.

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

Листинг 4. Пример определения задания для функции запуска процесса сборки
<taskdef name="startBuildActivity"
classname="com.ibm.team.build.ant.task.StartBuildActivityTask" />

Определение, результаты и соответствующие артефакты сборки приведены на рисунке 3. Показаны три процесса сборки, идентифицируемые с помощью метки даты и времени сборки.

Log-файлы сборки
Во время сборки генерируются текстовые log-файлы. При использовании описанных в данной статье расширений создается несколько новых log-файлов, полезных при отладке.
 
Снимок состояния
Во время сборки создается снимок состояния исходного кода, хранящегося в системе управления исходными кодами Team Concert.
 
Артефакты сборки
Генерируемый при сборке war-файл хранится в записи сборки.
Примечание.
При работе с процессами сборки, генерирующими много больших объектов, желательно скопировать эти файлы в доступное место сети и опубликовать ссылку на артефакты результата сборки.

Также включается список элементов работ, поставка которых была осуществлена и зафиксирована в результатах сборки. Это помогает отобразить связь между различными элементами жизненного цикла процесса разработки программного обеспечения (см. рисунок 3).

Рисунок 3. Иерархия контента, генерируемого процессом сбор
Рисунок 3. Иерархия контента, генерируемого процессом сбор
Рисунок 3. Иерархия контента, генерируемого процессом сбор

Запись сборки дополняется подробной информацией о наборе изменений, связанном с заданием (см. рисунок 4). Последовательность операций, сгенерировавших эти связанные данные, такова:

  1. Разработчику присваивается номер задания Rational Team Concert 1239.
  2. Разработчик изменяет (или создает) три файла исходного кода на java и файл build.xml проекта.
  3. Изменения четырех файлов группируются в один набор изменений, который затем связывается с заданием разработчика.
  4. После этого задание поставляется в общий поток заданий, используемый разработчиком.
  5. Сразу после поставки запускается плановый процесс сборки, и только что поставленный набор изменений определяется как новое изменение, выполненное после последней сборки. Задание добавляется в список элементов работ в запись сборки.
Рисунок 4. Иерархия артефактов расширенной сборки – 1
Рисунок 4. Иерархия артефактов расширенной сборки – 1
Рисунок 4. Иерархия артефактов расширенной сборки – 1

Рисунок 5 детализирует эту схему и демонстрирует связь задания разработчика с другими элементами жизненного цикла разработки ПО, такими как:

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

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

Рисунок 5. Иерархия артефактов расширенной сборки – 2
Рисунок 5. Иерархия артефактов расширенной сборки – 2
Рисунок 5. Иерархия артефактов расширенной сборки – 2

Этап 1. Резюме

На первом этапе выполняется простое изменение в безопасности процесса компоновки и добавляется несколько свойств. Также исследуется связь между жизненным циклом разработки в Rational Team Concert и соответствующими продуктами.

Этап 2. Загрузка WAR-файла в UrbanCode Deploy CodeStation

На этом этапе расширения файла build.xml к UrbanCode Deploy подключается клиент командной строки и сгенерированный WAR-файл загружается в область хранения версий продукта UrbanCode Deploy, именуемую CodeStation.

Примечание.
CodeStation – это не отдельный продукт, а просто название области хранения версий в UrbanCode Deploy.

Каждый компонент UrbanCode Deploy может хранить несколько версий файлов для развертывания на целевых системах. Можно выбирать различные версии для развертывания в различных средах и перемещать конкретную версию компонента по последовательности сред к производственной среде, выполняя в этих средах ряд тестов и проверок корректности работы. На рисунке 6 показан результат загрузки WAR-файла в UrbanCode Deploy.

Рисунок 6. Загрузка контента сборки в UrbanCode Deploy
Рисунок 6. Загрузка контента сборки в UrbanCode Deploy
Рисунок 6. Загрузка контента сборки в UrbanCode Deploy

Свойства

Используемые в процессе сборки свойства рекомендуется хранить в виде последовательности определений в начале файла build.xml. Если свойства необходимо менять (а такая необходимость возникнет, если вы захотите применить эти файлы в своей среде), сгруппируйте их. Это облегчит выполнение изменений.

Свойства, приведенные в листинге 5, устанавливают соединение с сервером UrbanCode Deploy и определяют компонент, в котором создаются новые версии. Использование маркера аутентификации устраняет необходимость хранить пароли в виде простого текста в файле build.xml. Имя сервера и маркер аутентификации для развертывания в UrbanCode должны соответствовать вашей среде.

Листинг 5. Свойства
<!-- Свойства подключения UrbanCode Deploy -->
<property name="Deploy_WebURL" value="https://rational-srv-02:8443" />
<property name="Deploy_AuthToken" value="6b29ed7f-956b-46ed-97ac-f3cbd4e6e876" />
<property name="Deploy_Component" value="Sample Component" />

Свойства, приведенные в листинге 6, позволяют версии компонента UrbanCode Deploy хранить ссылку на запись сборки в Rational Team Concert.

Листинг 6. Хранение ссылки на запись сборки RTC
<!-- Информация RTC, используемая в UrbanCode для создания ссылки на запись компоновки RTC --> 
<property name="Deploy_Component_Version_Backlink" value = "Team Concert Build Record" />
<property name="CCM_URL" value="https://rational-srv-02:9443/ccm" />
<property name="BackLink_Base_URL"
	value="${CCM_URL}/web/projects/…#action=com.ibm.team.build.viewResult&amp;id=" />

Лицо, ответственное за процесс развертывания, может быстро найти соответствующую запись сборки, а затем элементы работ для этой сборки. Дополнительные ссылки трассировки позволяют перейти к требованиям и контрольным тестам, если эти возможности набора продуктов Rational используются.

Примечание.
Последний элемент в листинге 6 приведен в сокращенном виде. Для определения URL-адреса записи сборки для вашего сайта и проекта Rational Team Concert загрузите запись сборки в Web-браузер и скопируйте URL-адрес начиная с названия проекта и включая &id=. Идентификатор сборки, следующий за &id=, добавляется в рамках процесса формирования URL-адреса, описанного в данной статье (см. Этап 4).

Примечание.
В URL-адресе, показанном в листинге 6, используется &amp;.

Листинг 7 – это log-файл, который используется для сбора информации о процессе создания версии компонента. При возникновении ошибок этот файл является полезным источником информации для отладки.

Листинг 7. Log-файл для сбора информации
<!-- Log-файлы для регистрации событий подключения к UrbanCode Deploy --> 
<property name="DeployComponentVersionCreate"
		value="${workingDir}/DeployComponentVersionCreate.log" />

Цель сборки Deploy

В файл build.xml добавляется новая цель для указания заданий, взаимодействующих с UrbanCode Deploy. Это позволяет выбирать время выполнения операций взаимодействия в процессе развертывания и дает возможность быстро вернуться к компиляции и модульному тестированию без взаимодействия с UrbanCode Deploy.

Добавляемая цель содержится в строках build.xml (см. листинг 8).

Листинг 8. Добавление цели
<target name="deploy" depends="compile">
</target>

Новая цель зависит от процесса компиляции, требующего создания нового WAR-файла перед добавлением его в новую версию компонента в UrbanCode Deploy.

Чтобы операция развертывания выполнялась при каждом запуске сборки, необходимо включить цель Deploy в основную цель сборки (см. листинг 9).

Листинг 9. Цель Deploy
<target name="all"
depends="compile, deploy" />

Интерфейс командной строки UrbanCode Deploy

Перед выполнением дальнейших действий необходимо установить интерфейс командной строки UrbanCode Deploy. Этот интерфейс можно загрузить из меню tools в правой части web-интерфейса UrbanCode Deploy. Распакуйте zip-файл на сервере сборки и добавьте выбранное местоположение в системный путь сервера. Остановите и перезапустите выполняющийся механизм сборки из окна командной строки. Если этого не сделать, процесс механизма сборки не сможет обратиться к интерфейсу командной строки UrbanCode.

Вход в UrbanCode Deploy

Первым действием цели Deploy является вход в UrbanCode Deploy. Это первое использование интерфейса командной строки udclient с аргументом login и подаргументами для маркера аутентификации и url-адреса подключения. Все параметры указываются в определенных ранее свойствах. Команда build.xml для входа приведена в листинге 10.

Листинг 10. Команда вход
<exec executable="cmd" dir="${workingDir}">
    <arg value="/c"/> 
    <arg value="udclient"/> 
    <arg value="login" /> 
    <arg value="-authtoken"/> 
    <arg value="${Deploy_AuthToken}"/> 
    <arg value="-weburl"/> 
    <arg value="${Deploy_WebURL}"/> 
</exec>

Отчет о ходе сборки с помощью StartBuildActivity

Команда сборки StartBuildActivity выполняется в начале многих операций, рассматриваемых в данной статье. Она сообщает о выполняемой операции пользователю, наблюдающему за процессом сборки в Eclipse или в Web-интерфейсе. Она также фиксирует этап сборки в записи сборки. Запись сборки размещается в базе данных Rational Team Concert. На рисунке 7 показан пример отчета о ходе сборки в пользовательском интерфейсе Eclipse.

Рисунок 7. Отчет о ходе сборки
Рисунок 7. Отчет о ходе сборки
Рисунок 7. Отчет о ходе сборки

Поле label выражения StartBuildActivity содержит ссылку на имя компонента, определенного в разделе свойств в начале файла.

Листинг 11. StartBuildActivity
<startBuildActivity activityIdProperty="CreateDeployComponentVersion"
    label="Create new component version - ${Deploy_Component}"
    buildResultUUID="${buildResultUUID}" 
    repositoryAddress="${repositoryAddress}"
    userId="${userId}" passwordFile="${passwordFile}" 
    autoComplete="true" />

Создание версии компонента в UrbanCode Deploy

После входа необходимо создать новую версию компонента в UrbanCode Deploy. Изначально новая версия не имеет контента, поскольку он добавляется позже на отдельном шаге. Первый аргумент команды аналогичен аргументу команды login, а остальными параметрами являются параметр createVersion, идентификаторы для компонента и имя создаваемой версии. Имя версии, указанное в ${buildLabel}, передается в ant процессом сборки Rational Team Concert. По умолчанию меткой сборки являются ее дата и время.

Листинг 12. Аргументы
<exec executable="cmd" dir="${workingDir}"
    output="${DeployComponentVersionCreate}" >
    <arg value="/c"/>
    <arg value="udclient"/>
    <arg value="-authtoken"/> 
    <arg value="${Deploy_AuthToken}"/> 
    <arg value="-weburl"/> 
    <arg value="${Deploy_WebURL}"/> 
    <arg value="createVersion"/> 
    <arg value="-component"/>  
    <arg value="&quot;${Deploy_Component}&quot;"/> 
    <arg value="-name"/> 
    <arg value="${buildLabel}"/> 
</exec>

Последней командой в процессе создания версии является сохранение log-файла, созданного при выполнении команды createVersion (см. листинг 12). Аргумент output ссылается на параметр, определенный ранее в файле build.xml, который хранится в структуре каталогов машины сборки. Log-файл публикуется в записи сборки Rational Team Concert при помощи команды, приведенной в листинге 11. Текстовое описание log-файла содержит имя компонента, поэтому при выполнении объемных сборок с множеством компонентов пользователи могут определить, с каким компонентом связан конкретный log-файл.

Листинг 13. Хранилище log-файла
<logPublisher filePath="${DeployComponentVersionCreate}"
    label="Create new component version - ${Deploy_Component} / ${buildLabel}"
    buildResultUUID="${buildResultUUID}" repositoryAddress="${repositoryAddress}" 
    userId="${userId}" passwordFile="${passwordFile}" verbose="true"/>

Добавление контента в новую версию компонента

После создания версии компонента в UrbanCode Deploy необходимо загрузить развертываемый контент в версию. Первым шагом создания контента версии является выполнение команды сборки StartBuildActivity.

Вторым шагом является выполнение команды udclient для загрузки нового контента в версию компонента в UrbanCode Deploy. Первые аргументы аналогичны аргументам команды login. Также включены команда addVersionFiles, идентификаторы компонента и местоположение загружаемых файлов.

Листинг 14. Обновление версии
<startBuildActivity activityIdProperty="AddDeployComponentVersion"
    label="Add component version to CodeStation - ${Deploy_Component}"
    buildResultUUID="${buildResultUUID}" repositoryAddress="${repositoryAddress}"
    userId="${userId}" passwordFile="${passwordFile}" autoComplete="true" /> 

<exec executable="cmd" dir="${workingDir}" >
    <arg value="/c"/> 
    <arg value="udclient"/> 
    <arg value="-authtoken"/> 
    <arg value="${Deploy_AuthToken}"/> 
    <arg value="-weburl"/> 
    <arg value="${Deploy_WebURL}"/> 
    <arg Value="addVersionFiles"/> 
    <arg Value="-component"/> 
    <arg Value="&quot;${Deploy_Component}&quot;"/> 
    <arg Value="-version"/> 
    <arg Value="${buildLabel}"/> 
    <arg Value="-base"/> 
    <arg Value="${destdir.distro}"/> 
    <arg Value="-include"/> 
    <arg Value="${target.war}"/> 
</exec>

Этап 2. Резюме

После второго этапа процесс непрерывной поставки перемещает контент из Rational Team Concert в UrbanCode Deploy в виде новой версии компонента, содержащей только что созданный war-файл.

Этап 3. Создание ссылки на версию компонента в записи сборки RTC

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

Формат ссылки: https://<имя сервера UrbanCode>:<защищенный порт UrbanCode>/#version/<идентификатор версии компонента>.

Целью следующих разделов является получение идентификатора версии компонента, формирование URL-адреса и сохранение его в записи сборки Team Concert.

Получение идентификатора версии компонента

Идентификатор версии компонента можно извлечь из результата (в JSON-формате) выполнения команды createVersion, рассмотренной выше. Для этого из сценария сборки вызывается Java-приложение, обрабатывающее результаты работы команды createVersion и извлекающее идентификатор. Исходный код Java-приложения прилагается к данной статье вместе с другими файлами (файл getJSONPropertyValue.zip). Имеется также файл build.xml для его сборки. Сборка исполняемого файла выполняется путем создания определения сборки в Rational Team Concert. После сборки добавьте сгенерированный jar-файл в каталог JKEBuildScripts \ sample.jke.build \ Support \ get-JSON-property-value.jar и выполните поставку его в поток. Следуйте рекомендациям по поставке файла build.xml после выполнения изменений.

Для выполнения приложения из файла build.xml в раздел свойств в начале файла помещается ряд дополнительных свойств. Добавляемые свойства приведены в листинге 15.

Листинг 15. Дополнительные свойства
<!-- Свойства для обрабатывающего JSON приложения, которое будет извлекать идентификатор версии компонента --> 
<property name="getJSONPropertyValue"
    value="${workingDir}/Support/get-JSON-property-value.jar"/>
<property name="getJSONPropertyValue-Log" value="${workingDir}/getJSONPropertyValuelog.txt"/>
<property name="DeployComponentVersionCreationIDFile"
    value="${workingDir}/DeployComponentVersionCreationIDFile.txt"/>
<property name="VersionCreationJSONTitle" value="id"/>

В цель Deploy после добавленных на этапе 2 команд добавляется раздел path. Это позволяет java-среде найти скомпилированный jar-файл.

Листинг 16. Добавление раздела path
<path id="getJSONPropertyValuePaths">
    <pathelement path="."/> 
    <pathelement path="${getJSONPropertyValue}" /> 
</path>

Затем выполняется команда java для обработки данных из команды createVersion. Аргументами команды являются:

  • Input file (входной файл): выходной файл рассмотренной выше команды createVersion.
  • Title (заголовок): заголовок JSON-формата, для которого необходимо извлечь значение.
  • Output file (выходной файл): имя создаваемого файла. Этот файл содержит извлеченные данные.

Пример входного файла показан ниже. Поле id является обязательным.

Листинг 17. Входной файл
{
    "id": "1044c181-b77c-4468-b1e8-0fc72cc370e0",
    "name": "I20140506-2120",
    "type": "FULL",
    "created": 1399407705637,
    "active": true,
    "archived": false
}

Раздел xml, необходимый для выполнения java-приложения с требуемыми свойствами, приведен в листинге 18.

Листинг 18. XML с необходимыми свойствами
<java jar="${getJSONPropertyValue}" output="${getJSONPropertyValue-Log}" fork="true">
    <classpath refid="getJSONPropertyValuePaths" />
    <arg value="inputFile=${DeployComponentVersionCreate}" />
    <arg value="Title=${VersionCreationJSONTitle}" />
    <arg value="outputFile=${DeployComponentVersionCreationIDFile}" />
</java> 

После выполнения команды создается выходной файл. Выходной файл содержит идентификатор версии компонента: 1044c181-b77c-4468-b1e8-0fc72cc370e0.

Следующим шагом является чтение содержимого файла и присвоение идентификатора свойству для его дальнейшего использования. Команда для загрузки файла в свойство приведена в листинге 19. В листинг также включена команда echo для отображения идентификатора в log-файле сборки.

Листинг 19. Команда загрузки файла
<loadfile property="DeployComponentVersionCreationID"
srcFile="${DeployComponentVersionCreationIDFile}"/> 
<echo message="ID of Component version =${DeployComponentVersionCreationID}" />

Публикация ссылки на версию компонента в записи сборки

С помощью команды Rational Team Concert link publisher опубликуйте URL-адрес, сформированный из URL заголовка, указанного в свойстве в начале файла, а также идентификатора, извлеченного из файла на предыдущем шаге. Добавьте свойство Header URL в файл build.xml, как показано в листинге 20.

Листинг 20. Свойство Header URL
<property name="DeployVersionLinkHeader" value="${Deploy_WebURL}/#version/"/> 
Листинг 21. Публикация ссылки
<!-- Публикация ссылки на версию компонента Deploy в результате сборки RTC -->
<linkPublisher label="UrbanCode Deploy Component - ${Deploy_Component}"
url="${DeployVersionLinkHeader}${DeployComponentVersionCreationID}"
componentName="Component Versions" buildResultUUID="${buildResultUUID}"
repositoryAddress="${repositoryAddress}" userId="${userId}"
passwordFile="${passwordFile}" failOnError="false" />

Этап 3. Резюме

После третьего этапа процесс непрерывной поставки может перемещать контент из Rational Team Concert в UrbanCode Deploy. Также создается ссылка из записи сборки на версию компонента.

Этап 4. Создание ссылки на запись сборки из версии компонента

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

Свойства

Перед командой exec добавляется новое свойство (см. листинг 22) для URL обратной ссылки, построенной из значений, ранее определенных в файле build.xml.

Листинг 22. Добавление нового свойства
<property name = "Build_Backlink" value = "${BackLink_Base_URL}${buildResultUUID}" />

Команда в файле build.xml для создания и публикации ссылки приведена в листинге 23.

Листинг 23. Создание и публикация ссылки
<exec executable="cmd">
    <arg value="/c"/>
    <arg value="udclient"/>
    <arg value="-authtoken"/>
    <arg value="${Deploy_AuthToken}"/>
    <arg value="-weburl"/>
    <arg value="${Deploy_WebURL}"/>
    <arg value="addVersionLink"/>
    <arg value="-component"/>
    <arg value="&quot;${Deploy_Component}&quot;"/>
    <arg value="-version"/>
    <arg value="${buildLabel}"/>
    <arg value="-linkName"/>
    <arg value="&quot;${Deploy_Component_Version_Backlink}&quot;"/>
    <arg value="-link"/>
    <arg value="&quot;${Build_Backlink}&quot;"/>
</exec> 

Созданные на этапе 3 связи показаны на рисунке 8.

Рисунок 8. Связи между UrbanCode Deploy и Rational Team Concert
Рисунок 8. Связи между UrbanCode Deploy и Rational Team Concert
Рисунок 8. Связи между UrbanCode Deploy и Rational Team Concert

Этап 4. Резюме

На этапе 4 мы указали процессу непрерывной поставки поместить контент из Rational Team Concert в UrbanCode Deploy и создали ссылку из версии компонента на запись сборки.

Резюме

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=1014081
ArticleTitle=Непрерывная поставка с помощью Rational Team Concert и UrbanCode Deploy: Часть 2. Расширение процесса сборки
publish-date=08282015