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

Часть 1. Готовая реализация

Comments

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

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

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

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

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

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

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

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

Ключевые концепции и понятия

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

Поток (stream)
Потоки служат пунктами сбора изменений. Они содержат совокупный результат всей разработки. Пользователи поставляют (deliver) изменения в поток и принимают (accept) из потока изменения, поставленные другими пользователями, тем самым поддерживая свою рабочую область в актуальном состоянии. Поток аналогичен концепции ветви (branch) во многих других системах управления версиями.
 
Набор изменений (change set)
Изменения файлов, контролируемых системой управления версиями в Rational Team Concert, необходимо регулировать и отслеживать. Наборы изменений представляют собой механизм группирования изменений файлов и каталогов в наборы, логически составляющие завершенный блок работы. Такое группирование выполняется в рамках процесса возврата (check-in) в Rational Team Concert. В большинстве сценариев набор изменений связывается с элементом работы (например, с заданием или дефектом), что позволяет сделать видимым контекст набора изменений. Посредством наборов изменений члены группы разработки могут просматривать выполненные изменения и проверять соответствие элемента работ требованиям.
 
Поставка (delivery
Поставка – это передача изменений из изолированной рабочей области разработчика в поток, связанный в данный момент времени с рабочей областью. Результатом операции поставки является сохранение в потоке новых файлов или новых версий файлов, которые становятся доступными для других разработчиков, связанных с этим потоком. Пользовательский интерфейс Rational Team Concert проинформирует этих разработчиков о появлении новых изменений, и они смогут выбрать подходящее время для их принятия.
 
Принятие (accept)
Принятие – это процесс обновления рабочей области пользователя новым содержимым файлов, поставленных другими пользователями.
 
Рабочая область пользователя
Каждый пользователь имеет рабочую область репозитория, связанную с потоком, в который он передает свою работу. Когда пользователь выполняет изменение в файле, отредактированная копия сохраняется в песочнице на стороне клиента, связанной с рабочей областью репозитория. Когда пользователь заканчивает вносить изменения, файл регистрируется и копируется из клиентской области репозитория в серверную. Файл передается в набор изменений вместе с другими файлами, которые также были изменены пользователем. После завершения формирования набора изменений пользователь передает его в поток.

Совместная разработка в Rational Team Concer

На рисунке 1 показана схема взаимодействия пользователя с потоком. Пользователь 1 регистрирует изменения файла в рабочей области репозитория на сервере и создает новый набор изменений. Набор изменений связывается с элементом работы для предоставления контекста набора изменений. Затем элемент работы (и связанный с ним набор изменений) передается в общий поток. Разработчик 2 принимает изменения, его рабочая область репозитория обновляется и изменения файлов копируются на локальный жесткий диск, на котором хранятся его файлы репозитория.

Рисунок 1. Регистрация, поставка и принятие в потоке
Рисунок 1. Регистрация, поставка и принятие в потоке
Рисунок 1. Регистрация, поставка и принятие в потоке

Непрерывная интеграция

На рисунке показан пример взаимодействия в рамках процесса непрерывной интеграции.

Рисунок 2. Совместная работа с исходным кодом приложения и автоматизация сборки
Рисунок 2. Совместная работа с исходным кодом приложения и автоматизация сборки

На рисунке 2 три разработчика работают совместно, используя общий поток разработки. Например, Джон завершает часть работы и поставляет ее в поток разработки. Сью и Крис могут принять эту работу в свою рабочую область для интеграции выполненных Джоном изменений со своей работой. Этот процесс создает среду совместной разработки, в которой разработчики имеют необходимый для выполнения своей работы уровень изоляции в рамках своей рабочей области, но при этом участвуют в управляемом процессе интеграции, основанном на потоке разработки. Предусмотрена специальная рабочая область, подключенная к процессу сборки. Периодически (с заданной частотой, которая может достигать одного раза в минуту) активизируется процесс сборки, и рабочая область сборки ищет новые изменения, поставленные в поток разработки. Если обнаруживается, что с момента последней сборки никаких изменений не было, сборка просто останавливается. Если обнаруживаются новые подтвержденные изменения, выполняется сборка и генерируются результаты, содержащие соответствующие записи созданных двоичных объектов и проведенных модульных тестов. На рисунке 3 показан подробный пример процесса сборки. Джон завершил работу с двумя наборами изменений (связанными с элементами работ 2012 и 2013). Джон передает изменения в общий поток, что приводит к появлению приглашения для Джона и Сью принять изменения и обновить свои рабочие области. Затем Крис завершает работу над дефектом 1985 и поставляет элемент работы и связанный с ним набор изменений. Джон и Сью принимают этот набор изменений в своих рабочих областях.

Рисунок 3. Пример изменений, поставленных и собранных в запись сборки
Рисунок 3. Пример изменений, поставленных и собранных в запись сборки
Рисунок 3. Пример изменений, поставленных и собранных в запись сборки

Запланированный процесс сборки запускается после выполнения пользователями операций поставки, рассмотренных в разделе Ключевые концепции и понятия процесса поставки. Полученные log-файлы и двоичные объекты сохраняются в записи сборки Rational Team Concert и генерируется новый снимок состояния (snapshot). Снимок состояния связывается с записью сборки. В большинстве случаев результатом процесса сборки является создание двоичных объектов, таких как JAR-файл, WAR-файл, EAR-файл, EXE-файл или файл другого формата. Беспрепятственная компоновка кода интегрированного приложения и успешное прохождение всех автоматических модульных тестов являются показателем качества работы и свидетельством того, что участники проекта работают на общую цель. Однако многие группы стремятся пойти дальше и распространить этот процесс на развертывание приложения в исполняющей среде для последующего тестирования.

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

Размер этой статьи не позволяет предоставить подробную информацию о процессе сборки в Rational Team Concert и о файлах build.xml. Дополнительную информацию по созданию процесса сборки в Rational Team Concert можно найти в справочной системе по продукту и во многих Web-публикациях:

В статье Использование CLM для сборки CLM (EN) приведена подробная информация о том, как группа разработчиков IBM выполняет сборку семейства продуктов Rational Jazz при помощи Rational Team Concert.

Непрерывная поставка

При создании процесса непрерывной поставки необходимо реализовать дополнительные задачи по фактической установке двоичных объектов в исполняющей среде. Rational Team Concert отвечает в этом процессе за сборку и модульное тестирование (этап непрерывной интеграции), а UrbanCode Deploy – за развертывание. Проще говоря, границей между двумя продуктами является готовый к развертыванию двоичный файл. Rational Team Concert генерирует двоичный файл, а UrbanCode Deploy принимает этот файл и развертывает его в исполняющей среде.

Имея приложение, развернутое в исполняющей среде, группа разработки может выполнять более реалистичные функциональные тесты и тесты производительности и безопасности. Это одна из причин того, почему операция развертывания имеет такое значение. Кроме того, этот процесс делает операцию развертывания частью стандартной рабочей процедуры и гарантирует знакомство всех членов группы со средой развертывания, требованиями к развертыванию и проблемами, возникающих при неудачном развертывании. На протяжении многих недель группа разработки выполняет сотни (а, возможно, и тысячи) операций развертывания приложения в средах разработки и QA-средах. В результате на этапе разработки процесс развертывания приложения тестируется, настраивается и изменяется до тех пор, пока не будет достигнута твердая уверенность в готовности к развертыванию в предпроизводственной и производственной средах.

Простой процесс непрерывной поставки

Простой процесс непрерывной поставки можно создать при помощи графических механизмов подключения процесса сборки в Rational Team Concert к решению UrbanCode Deploy для автоматизированного развертывания. В Rational Team Concert версии 4.0.5 была добавлена новая опция Post-build Deploy (развертывание после сборки), позволяющая процессу сборки взаимодействовать с UrbanCode Deploy. Эту функциональность можно добавить к существующему процессу сборки, открыв определение сборки. Щелкните левой кнопкой мыши на словах Build Definition в верхней части экрана и выберите Configure. Опция Post-build Deploy находится на вкладке Post-build.

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

Рисунок 4. Добавление параметра Post-build Deploy в существующую сборку
Рисунок 4. Добавление параметра Post-build Deploy в существующую сборку
Рисунок 4. Добавление параметра Post-build Deploy в существующую сборку

Настройка развертывания после сборки

Процесс развертывания после сборки требует задания пользователем некоторых свойств. Необходима следующая информация:

  1. URL-адрес сервера UrbanCode Deploy.
  2. Имя пользователя для регистрации на UrbanCode Deploy.
  3. Пароль или маркер аутентификации для пользователя, определенного на шаге 2.
  4. Имя компонента, в котором должна сохраняться новая версия компонента.
  5. Имя версии, предоставляемое вновь созданному компоненту. Обычно как минимум для части имени используется идентификатор сборки (применяется синтаксис ${buildLabel}).
  6. Ссылка на базовый каталог, идентифицирующая раздел, в который сохраняются артефакты сборки. Из этого базового местоположения берется содержимое, которое нужно сохранить в новой версии компонента в UrbanCode Deploy.
  7. Набор файлов, которые нужно включить в новую версию компонента. Указывается шаблон для включаемых файлов. Шаблон **/* означает включение всех файлов.
  8. Набор файлов, которые нужно исключить из новой версии компонента.
  9. Все свойства, которые нужно скопировать в UrbanCode Deploy. Они добавляются в версию компонента как новые свойства в виде пар имя/значение. Эти свойства используются при операциях развертывания. Формат свойств: : snapshotUUID=${team.scm.snapshotUUID}.
  10. Все ссылки для создания в версии компонента UrbanCode Deploy, например, обратная ссылка на запись сборки в Rational Team Concert. Синтаксис ссылки можно увидеть, загрузив любую запись сборки в браузер и скопировав соответствующий раздел URL-адреса. Пример полной ссылки на запись сборки:
    https://rational-srv-02:9443/ccm/web/projects/
    JKE%20Banking%20%28Change%20Management%29#action=com.ibm.team.build.viewResult
    &id=_KclYURb0EeSlFMEP2zrMSg

Добавляемому результату сборки соответствует полный URL-адрес до знака '=' включительно. Оставшийся идентификатор результата сборки заменяется параметром ${buildResultUUID}.
Примечание.
Адрес репозитория также заменяется параметром, приведенным в листинге 1.

Листинг 1. Результат сборк
Build Result=${repositoryAddress}web/projects/JKE%20Banking%20%28Change%20Management%29#
action=com.ibm.team.build.viewResult&id=${buildResultUUID}
  1. В последнем разделе конфигурации развертывания после сборки содержится индикатор запуска процесса развертывания после загрузки новой версии компонента.
  2. При необходимости запуска процесса развертывания пользователь должен указать:
    • Приложение UrbanCode Deploy
    • Среду, в которой выполняется развертывание приложения.
    • Выполняемый процесс.

На рисунках 5-7 показана полная конфигурация развертывания после сборки.

На рисунке 5 показаны параметры подключения к серверу и учетные данные пользователя для установки соединения с UrbanCode Deploy.

Рисунок 5. Развертывание после сборки – подключение к сервер
Рисунок 5. Развертывание после сборки – подключение к сервер
Рисунок 5. Развертывание после сборки – подключение к сервер

На рисунке 6 показана страница Publish Artifacts, на которой указывается имя компонента, принимающего поставляемые активы новой версии. Можно также указать идентификатор версии, используемый сервером UrbanCode Deploy для именования новой версии. В примере, показанном на рисунке 6, в синтаксисе ${BuildLabel} используются дата и время, указанные в записи сборки в Rational Team Concert.

Рисунок 6. Развертывание после сборки – публикация артефактов
Рисунок 6. Развертывание после сборки – публикация артефактов
Рисунок 6. Развертывание после сборки – публикация артефактов

На рисунке 7 показан процесс, запускаемый после публикации новой версии компонента в UrbanCode Deploy. Вызов процесса развертывания не обязателен и определяется состоянием флажка Deploy (см. рисунок 7). Для выполнения развертывания введите имя приложения, исполняющую среду и используемый процесс.

Рисунок 7. Развертывание после сборки – форма запроса процесс
Рисунок 7. Развертывание после сборки – форма запроса процесс
Рисунок 7. Развертывание после сборки – форма запроса процесс

Результаты выполнения развертывания после сборки

В результате успешного выполнения операции развертывания после сборки выбранные файлы из процесса сборки сохраняются в новой версии идентифицированного компонента в UrbanCode Deploy. Эта версия компонента развертывания UrbanCode содержит обратную ссылку на запись сборки Rational Team Concert. При выборе этой ссылки в UrbanCode Deploy в Web-браузере откроется запись сборки.

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

Заключение

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


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


Похожие темы


Комментарии

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

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