Изначально, схемы Rational ClearQuest поставляются в некоторой базовой комплектации, которая в дальнейшем расширяется пакетами обновлений. К расширению схемы можно отнести: создание новых типов записей, обслуживающих новые бизнес-правила, усовершенствование старых, посредством добавления полей, сценариев и т.п. В основном пакеты поставляются самой Rational в рамках парадигмы UCM. Однако ничего не мешает созданию собственных пакетов, то есть фактически 3rd-party пакетов. Рассмотрим один из подходов в создании пакетов на примере пакета EmailRuleExtension (механизм расширения почтовых правил).

Термины

Пакет (package) – обновление схемы, содержащее всю необходимую информацию (поля, состояния, действия, формы, матрица переходов и сценарии) по обновляемому/устанавливаемому типу записи. Дельта схемы – текстовый файл, содержащий перечень изменений произведенных над схемой в некотором диапазоне ревизий схемы. «Чистая» схема – схема, в которой отсутствуют элементы пакета

Описание

Скажем, мы захотели усовершенствовать функциональность схемы ClearQuest путем внедрения механизма расширения почтовых правил (РПП). Для этого необходимо создать дополнительный тип записи Email_Rule_Extension, населить его полями и действиями, добавить необходимые поля для Defect и ChangeRequest, написать необходимые сценарии. Все эти доработки схемы определяют нам ту дельту схемы (по сути дела пакет обновления), в которой усовершенствована функциональность схемы. Дельта задается начальной ревизией схемы – когда механизм РПП еще не был внедрен, и конечной – когда механизм успешно внедрен и протестирован. Таким образом, для создания «чистого» отчуждаемого пакета необходимо тщательно следить, чтобы помимо действий связанных с внедрением новой функциональности, схема по возможности не менялась. Далее рассмотрим метод создания пакета, на основе выделения его из дельты.

Создание пакета методом выделения из дельты

1. Выгрузка дельты с помощью утилиты cqload: cqload exportintegration -dbset CQMS.INITDEV.INITS Savitsky ***** DefectTracking 141 142 Email_Rule_Extension "e:\cq\package_full_base.script" DefectTracking – название схемы, из которой выгружается дельта в диапазоне 141 – 142. Email_Rule_Extension – название типа записи, чьи ревизии выгружаются. Название файла, в который будет производиться выгрузка схемы желательно оставлять таким как в данном примере – оно жестко задается правилами оформления пакетов. 2. Оформление пакета Создать в каталоге «Program Files\Rational\ClearQuest\packages» подкаталог с названием пакета (EmailRuleExtension), затем в нем создать подкаталог с версией пакета (1.0). В подкаталоге с версией создать файл package.ini, содержащий описание пакета в следующей форме: [General] Name=EmailRuleExtension RevString=1.0 MetadataRevNumber=1 Description=Пакет расширения почтовых правил Policy=NOT IMPLEMENTED EntityTypeNames=placeholder Keywords= DllFileName=package_EmailRuleExtension.dll DllInterfaceVersion=1 CreationDate=2002-06-06 14:40:50 Author=Init-s Corporation MinFeatureLevel=3 MaxFeatureLevel=0 SchemaRevs=2 HasPlaceholder=False Поскольку назначение понятия «Placeholder» не совсем очевидно, а утилита cqload не способна к формированию необходимых файлов, то можно пойти по следующему пути. Необходимо заменить все вхождения последовательности %%INTGR_PE1%% в файле «package_full_base.script» на название типа записи Email_Rule_Extension. Внимание! Необходимо аккуратно производить замену. Большинство редакторов изменяют структуру этого файла, который содержит дополнительный символ 0x0D помимо комбинации переноса на следующую строку {0x0D,0x0A}. Подходящим редактором является UltraEdit-32. Также в файл «package_full_base.script» в начало заголовка необходимо вставить следующие строки (выделены жирным шрифтом): VERSION 22 SOURCE "Exported from Schema Repository (idcqrep on INITSQL) on Thu Jun 06 17:25:29 2002 " PACKAGE_NAME "EmailRuleExtension" PACKAGE_VERSION_STRING "" PACKAGE_METADATA_VERSION 1 SCRIPT_TYPE "PACKAGE_BASE" ENTITYTYPE_NAME "EmailRuleExtension" SUBMIT_FORMDEF_NAME "" DEFAULT_FORMDEF_NAME "" TYPEDEF entitydef... Для того чтобы с помощью графического интерфейса ClearQuest Designer можно было устанавливать новые пакеты, необходимо добавить информацию о пакете в реестр: REGEDIT 4 [HKEY_LOCAL_MACHINE\SOFTWARE\RationalSoftware\ClearQuestPackages\EmailRuleExtension] [HKEY_LOCAL_MACHINE\SOFTWARE\RationalSoftware\ClearQuestPackages\EmailRuleExtension\1.0] [HKEY_LOCAL_MACHINE\SOFTWARE\RationalSoftware\ClearQuestPackages\EmailRuleExtension\1.0\DataPath] "DataPath"="E:\\ProgramFiles\\Rational\\ClearQuest\\packages\\EmailRuleExtension\\1.0" 3. Тестирование пакета После создания пакета его необходимо протестировать – установить в «чистую» схему. Данная операция проводится с помощью ClearQuest Designer по следующим шагам: Если отсутствует «чистая» схема (схема, в которой не существует реализованной в пакете функциональности), ее можно создать (New schema) основываясь на той ревизии схемы, когда она еще была «чистой» (ассоциировать с базой данных не нужно). Выполнить CheckOut схемы и убедиться, что элементы пакета не установлены. Выполнить UndoCheckOut схемы. Открыть «Package Wizard», в списке должен находиться тестируемый пакет. Выбрать его из списка и нажать кнопку «Next». Выбрать те типы записей, к которым необходимо применить пакет. Убедиться, что все элементы пакета установлены в схему. Выполнить операцию «Validate» и если все хорошо, то удалить тестовую схему.

Выпуск новых версий пакета

Каждый раз, когда в пакете производятся какие-то изменения необходимо выпускать его новую версию. Применение новых версий пакета к схемам, во-первых, упростит задачу переноса функциональности между схемами, а во-вторых, будет гарантировать, что в таких схемах совершены одинаковые и предсказуемые изменения. Поскольку схема постоянно совершенствуется, то дельта схемы, из которой формируется новая версия пакета, так или иначе будет содержать посторонние (для пакета) изменения, что естественно нежелательно. Для модификации и выпуска новой версии пакета необходимо иметь такую схему, в которой все изменения являются следствием установки в нее пакета. Предлагается использовать следующий алгоритм модификации пакета: Пакет разрабатывается, модифицируется и тестируется на тестовой схеме. Создается «чистая» схема (не ассоциированная с базой данных) на основе ревизии тестовой схемы до установки пакета или начала реализации его функциональности. Номер такой ревизии можно определять по журналу изменений в тестовой схеме. Из тестовой схемы переносится доработанная функциональность пакета в «чистую» схему. Такого рода вторичное изменение схемы повышает контроль над этими изменениями, что в целом улучшает надежность схемы и не приводит к ее замусориванию. Производится выгрузка дельты и выделение пакета согласно описанному выше алгоритму. Увеличивается номер (ревизия) пакета (см. далее). Проводится тестирование пакета.       При создании новой версии пакета необходимо следить, чтобы ее номер был изменен во всех нужных местах: В названии подкаталога версии. В файле «package.ini» - ключ «MetadataRevNumber». В файле «package_full_base.script» - ключ «PACKAGE_METADATA_VERSION» в заголовке. В реестре необходимо создать новый ключ с новым номером версии. Значение «DataPath» должно содержать путь к новой версии пакета.