Рубрики

Свежие записи

Управление метаданными репозиториев в IBM Rational ClearCase

GD Star Rating
loading...
GD Star Rating
loading...




clip_image005Начинаю публикацию материалов, что называется, из загашников :) Статьи, методики, инструкции и прочее, связанное с IBM Rational и стандартами. Надеюсь, что этот труд кому-то пригодится :)

Будут вопросы — пишите комментарии!

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

Метаданные являются средством расширения и дополнения стандартных функций ClearCase, а также для добавления новых.

К метаданным относится следующее:

Типы элементов (element type);

Типы меток (label type);

Типы ответвлений (branch type);

Типы атрибутов (attribute type);

Типы триггеров (trigger type);

Типы гиперссылок (hyperlink type).

Все метаданные являются составной частью VOB, и могут быть использованы для:

Поддержки выбора элементов в версиях;

Определения критериев выбора элементов VOB;

Определения логического взаимодействия между объектами VOB;

Определения проектной схемы;

Логической связи элементов VOB с внешними объектами;

Действенного расширения функциональности;

Определения выпуска релизов.

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

Метаданные позволяют созвать новый тип определенных данных, которые впоследствии будут применены к элементам VOB. В связи с этим возникает необходимость в двойной работе: по созданию типа метаданных, и последующим назначением.

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

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

!!!Доступ к метаданным должен регламентироваться корпоративным стандартам, в соответствии с которым ведется проект

Контроль над метаданными можно проводить в прямом и косвенных режимах.

Прямой режим – это режим вызова специального модуля ClearCase – “Type Explorer” из закладки VOBs, основной консоли. В косвенном режиме возможно изменение метаданных без вызова данной консоли (обычно это происходит при создании профилей и при создании меток).

Также на метаданные можно воздействовать из командной строки. Для этих целей предусмотрен целый ряд команд, интерпретатора «cleartool».

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

clip_image002

Рисунок 1. Окно демонстрирует модуль Type Explorer. В виде папок отображаются точки входа в метаданные определенного типа.

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

На рисунке 1 показан фрагмент окна Type Explorer.

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

Типы элементов

Element Type

clip_image005

Element Type — позволяет группировать файлы и директории по определенным признакам (например по расширениям). Когда мы ставим файл под управление, ClearCase пытается, анализируя расширение, определить к какой группе предустановленных типов элементов его следует отнести. Это может быть текстовый файл, или исполняемый, или библиотека… и так далее.

Определить принадлежность файла еще важно потому, что на всех последующих операциях работы с элементом, будь то создание новой версии, или проведение сравнений или слияний, необходимо будет вызывать специальные программы из инструментария ClearCase. Например, операция сравнения, по умолчанию доступна только для текстовых файлов, однако, ClearCase, может сравнивать версии файлов MS Word, не являющихся текстовыми. Сравнение происходит путем вызова стандартных возможностей по сравнению, которые встроены в Word. Это возможно только благодаря тому, что типы простых текстовых файлов и файлов Word не совпадают, и, как следствие, ведут к вызову разных модулей при выполнении встроенных в ClearCase операций.

clip_image007

Рисунок 2. Список типов элементов VOB

Отметим основные предназначения модуля Element Type:

Идентифицировать элементы, устанавливаемые под контроль;

Классифицировать установленные элементы;

Определить список внешних модулей для работы над новым типом данных
(в соответствии с заранее предопределенными событиями);

Рисунок 2 показывает фрагмент экрана со списком предопределенных типов элементов.

У каждого типа элементов имеется определенный набор свойств, отметим наиболее важные из них:

Supertype. Определяет супертип для конкретного типа. Супертип, своего рода, предок из Объектно-Ориентированного программирования, определяющий основные действия для данного типа. Например, для всех проектных текстовые файлов можно использовать предка «text_file»;

Override type manager. Переменная (ссылка), определяющая вызов внешних приложений, необходимых для выполнения действий ClearCase (см. ниже);

Merge type. Определяет действия на операции слияния.

В совокупности, свойства определяют логику работы ClearCase с различными элементами. Идентификация элемента происходит на этапе постановки его под версионное управление. Полученный при идентификации тип элемента, сопровождает его на протяжении всего жизненного цикла. Узнать тип элемента из его свойств (property).

Magic-file и создание новых типов элементов

Для создания нового типа элемента, достаточно выбрать Type->Create, ввести имя и комментарий для вновь созданного типа. При этом создается новый тип элемента без определенной логической привязки и без предопределенных действий, то есть, по сути, мы получаем метаданные, которые нельзя применять на практике.

Во избежание этого имена метаданным даются в строгом соответствии с записями, находящимися в magic-файле.

Magic-файл – специальный текстовый файл (…\Rational\ClearCase\config\magic\default.magic), в котором описаны типы возможных элементов, и маска расширений или имен файлов, по которым ClearCase сможет их идентифицировать. Ниже приведен фрагмент Magic-файла:

zip_archive archive file : -name «*.[zZ][iI][pP]» ;

gtar_archive archive file : -name «*.gtar» ;

tar_archive archive compressed_file : -name «*.tar» ;

Формат его достаточно прост: имя, супертип и формат расширения.

При задании маски, возможно перечисление различных расширений, методом группировки логической операцией ИЛИ “|”. Например, как сделано для графического типа «JPG»:

jpeg_image image file : -name «*.[jJ][pP][eE][gG]» | -name «*.[jJ][pP][gG]» | -name «*.[Jj][pP][eE]» ;

Строка определения должна всегда заканчиваться знаком точка с запятой. Буквы, заключенные в квадратные скобки, описывают возможный регистр для букв в расширении.

Для того чтобы создать в метаданных тип «zip_archive», достаточно точно воспроизвести это имя при создании через Type->Create. Никаких дополнительных действий приводить не надо. ClearCase автоматически просматривает Magic-файл на предмет совпадения имен типов. Соответственно, при постановке под управление файла с расширением ZIP, ему будет присвоен тип элемента «zip_archive».

Создание новых типов не представляет сложностей, поскольку Magic-файл является расширяемым. Ограничение накладывается не на объем вносимых данных, а только на их соответствие установленному синтаксису. В качестве примера попробуем добавить новый тип архивного файла, отсутствующего в стандартном Magic-файле – RAR. Строка описания, при этом, будет выглядеть примерно так:

rar_archive archive file : -name «*.[rR][aR][rR]» ;

Для внесения строки в метаданные VOB остается только вписать «rar_archive» в имени типа.

Особый интерес для проектов может быть вызван способностью magic-файлов к группировке определенных файлов (посмотрите, как был сгруппирован JPG). Например, очень часто нужно группировать файлы с различными расширениями, но так, чтобы на концептуальном уровне они были представлены единым целым, скажем, «С», «ASM», «CPP», в проекте необходимо представлять как «project00987_sources».

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

Основные действия ClearCase над элементами.

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

Например, в базовой поставке, ClearCase может проводить операции сравнения для текстовых файлов, директорий, файлов Rose и файлов Word. Соответственно, объединять и сравнивать типы элементов, выходящих за рамки описанного, он не может. Например, не может сравнить два битовых изображения, или два архивных файла. Но для компании, занимающейся WEB-разработками, или компании, связанной с разработкой интерьеров, очень важно иметь возможность сравнивать графические имиджи.

Подобная возможность предусмотрена в ClearCase.

Поскольку ClearCase является событийно-ориентированным продуктом, то есть определенный ряд основных событий, в ответ на инициирование которых вызывается определенный модуль из состава ClearCase, или ЛЮБОЙ внешний. Рассмотрим список наиболее важных событий ClearCase:

construct_version. Конструирование версии;

create_branch. Создание ответвления. Выполняется при порождении новой ветви для элемента, находящегося под управлением;

create_element. Создание элемента. Инициируется при постановке элемента под управление ClearCase;

create_version. Создание версии элемента (результат операции check-in);

delete_branches_versions. Удаление версии ответвления;

compare. Сравнение двух или большего числа версий элемента;

merge. Слияние версий;

annotate. Формирование описания изменений в элементе (аннотирование изменений для всех версий элемента);

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

Для управления событиями используется два файла:

…\Rational\ClearCase\lib\mgrs\map – описание событий и модулей;

…\Rational\ClearCase\lib\mgrs\mgr_info.h – описание типов операций, для создания внешнего модуля.

Map-файл описывает события, типы элементов и имена вызываемых модулей. Типы элементы подбираются из архетипов элементов (см. выше), способствуя вызову строго определенных модулей на те или иные события для всех потомков.

Рассмотрим, в качестве примера, фрагмент Map-файла для типа «text_delta_file»:

text_file_delta construct_version ..\..\bin\tfdmgr.exe

text_file_delta create_branch ..\..\bin\tfdmgr.exe

text_file_delta create_element ..\..\bin\tfdmgr.exe

text_file_delta create_version ..\..\bin\tfdmgr.exe

text_file_delta delete_branches_versions ..\..\bin\tfdmgr.exe

text_file_delta compare ..\..\bin\cleardiff.exe

text_file_delta xcompare ..\..\bin\cleardiffmrg.exe

text_file_delta merge ..\..\bin\cleardiff.exe

text_file_delta xmerge ..\..\bin\cleardiffmrg.exe

text_file_delta annotate ..\..\bin\tfdmgr.exe

text_file_delta get_cont_info ..\..\bin\tfdmgr.exe

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

Обычно для этого применяют следующую практику:

Прописывают новый тип элемента в magic-файл (например, rar_archive);

Создают новый тип в Type Explorer (например, rar_archive);

Открывают текстовый файл MAP, копируют блок текста, имеющего отношение к «binary_delta» в конец файла;

Переименовывают «binary_delta» в «_rar_archive» (подчеркивание желательно применять во избежание конфликтов имен);

Вводят имена модулей, отвечающих за реализацию действий;

Последний шаг. В свойстве элемента rar_archive, в поле Override type manager прописывают «_rar_archive», находящийся в MAP-файле.

Работа из командной строки

Ниже приведен список команд, на которые необходимо обратить внимание, для управления типами элементов:

Mkeltype. Создание типа элемента;

Mkelement. Назначение типа элемента конкретному файлу (постановка данных под управление);

Rmtype. Удаление типов объектов;

Lstype. Просмотр типов объектов;

Describe. Просмотр свойств объектов.

Типы меток

Label Type

clip_image010

Метки представляют собой мощный механизм по формированию базовых линий, или, как еще называют, слепков проекта в определенный момент времени.

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

ClearCase представляет два способа нумерации версий файлов проекта автоматическую и ручную.

Автоматический способ нумерации работает в ClearCase с самого начала, и никакими корпоративными стандартами на него нельзя влиять: нумерация всегда идет с нуля, с шагом приращения один.

Ручной же способ подразумевает, при помощи меток, гибко управлять расположением релизов.

Метка ставится на определенные физические версии группы файлов проекта. Тем самым определяется принадлежность версии к определенному релизу.

clip_image011

Рисунок 3. Базовая линия (базовая версия, baseline).

На рисунке 3 показан пример подхода, в котором выделены версии файлов, относящиеся к версии релиза Rel1.

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

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

main.c@@/main/5;

lib1.c@@/main/2;

all.h@@/main/3.

Для некоторых специальных операций в ClearCase предусмотрены 3 предустановленных типа меток, которые не рекомендуется удалять или переименовывать, так как это может привести к непредсказуемым действиям продукта при выборе версий.

Рассмотрим их:

LATEST. Показывает на последнюю версию элемента. Данный тип метки не демонстрируется пользователю на экране в текстовом виде. LATEST необходим для получения содержимого последней версии;

CHECKEDOUT. Так помечается версия элемента, находящегося в состоянии check-out. Метка носит временный характер, и предназначена для визуального подсвечивания версии элемента на время действия check-out;

BACKSTOP. Обозначает версию элемента, находящуюся перед версией, находящейся в состоянии check-out. BACKSTOP также как и LATEST не отображается явным образом, но способствует правильному получению предыдущей версии элемента.

Создание меток из Type Explorer не представляет ничего сложного, принцип действия тот же, что и при создании типа элемента.

Работа с метками также происходит в два этапа: сначала создается тип, а затем назначается на конкретную версию элемента в VOB.

Работа из командной строки

Ниже приведен список команд, на которые необходимо обратить внимание, для управления типами меток:

Mklbtype. Создание типа метки;

Mklabel. Назначение типа элемента конкретному файлу (постановка данных под управление);

Rmtype. Удаление типов объектов;

Lstype. Просмотр типов объектов;

Describe. Просмотр свойств объектов.

Тип ответвлений

Branch Type

clip_image014

Одно из неоспоримых преимуществ ClearCase – система, позволяющая работать над одними и теми же данными разным участникам проекта. Механизм называется параллельная разработка. При параллельной разработке каждый разработчик может работать в изолированном пространстве, не мешая остальным участникам, проводя разработку очередного релиза. По завершении чего, он может внести изменения в проект, не испортив, при этом, версионную структуру. Ответвление данного типа называется «личное» (private), и может настраиваться каждым участником по усмотрению.

Второй тип возможного ответвления – формирование отладочного релиза для всего проекта.

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

По способам создания типов ответвлений и их назначением элементам различают два подхода: ручной и автоматический.

 

clip_image015

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

При автоматическом подходе (наиболее эффективном) ClearCase самостоятельно создает ветви и закрывает их. Здесь все решается на уровне правил View, которые определяют политику работы с ветками (см. ConfigSpec и Profiles).

 

clip_image017

Обратите внимание на рисунок 4, на котором продемонстрирована параллельная ветвь Rel1BugFix – отладочный релиз для группы файлов, с целью отлавливания ошибок и получения новой версии на основном дереве. После проведения всех регламентных работ над параллельной ветвью, ее изменения передают в основную ветвь методом слияния (merge). Что и показано на рисунке 5.

Для пояснения необходимости ветвления давайте рассмотрим классический случай из практики подавляющего большинства компаний разработчиков ПО. Имеется некая информационная система, внедренная n-ному числу заказчиков. Система взрослая, эволюционирует на протяжении 5 лет. За это время вышло 5 основных ее релизов (Rel1, Rel2, Rel3…).

Один из клиентов, срок тех. поддержки которого не истек, просит внести косметические изменения в версию Rel1. На новую версию Rel5, клиент не может перейти из-за существенно возросших аппаратных требований.

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

При использовании ClearCase стопора не возникает, так как VOB хранит историю изменений всех версий файлов. В определенные моменты делались «слепки» проекта (обратите внимание на метку Rel1), к которым всегда можно вернуться. Так при поступлении требования изменить первый релиз, разработчик создаст специальный вид обращения к базе и настроит его на метку Rel1. В результате получит полную среду, относящуюся к этому релизу. Как только он найдет элементы, подлежащие модификации, и выведет их в состояние check-out (для редактирования), ClearCase автоматически создаст ответвление (бренч) с именем Rel1BugFix (наименование бренча – часть корпоративного стандарта). После всех изменений над версиями бренч может быть переведен на основную ветвь. При этом получается промежуточные релиз Rel1.1, либо бренч остается «повисшим», а откомпилированный релиз отдается клиенту.

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

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

В ClearCase принято релизам давать метки типа Rel1.0 или Release1.0, соответственно бренч должен называться созвучно: Rel1.0BugFix или Release1.0BugFix. Это что касается отладочного релиза. Приватный релиз может носить любое имя, вплоть до имени разработчика.

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

На создание бренчей накладывается одно ограничение: на одном элементе не могут быть два бренча с одинаковым именем.

Адресация

Для управления и указания отладочных релизов в ClearCase применяется адресация ответвлений, сходная с адресацией каталогов в файловых системах. То есть для указания пути к бренчу необходимо через слеш перечислить всех его предком, начиная с main.

Например, для рисунка 5, адрес будет выглядеть так: /main/Rel1BugFix.

Это пример прямой адресации.

В ClearCase присутствует также косвенная адресация. В режиме косвенной адресации нет необходимости перечислять всех предков, поскольку каждый бренч уникален, и может присутствовать только в единственном числе. В этом случае используется специальный заполнитель – многоточие – «…».

Для того же рисунка 5 косвенный адрес будет выглядеть так: …/Rel1BugFix.

Таким образом можно формировать обращение к бренчу с любой вложенностью.

Создание типов бренчей

Тип создается из Type Explorer, либо через специальные системы (см. создание приватного ответвления, создание профилей), либо из командной строки.

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

Работа из командной строки

Ниже приведен список команд, на которые необходимо обратить внимание, для управления типами бренчей:

Mkbrtype. Создание типа ответвления;

Mkbranch. Назначение типа бренча конкретной версии элемента;

Rmtype. Удаление типов объектов;

Lstype. Просмотр типов объектов;

Describe. Просмотр свойств объектов.

Типы атрибутов

Attribute type

clip_image020 clip_image022

Расширить возможности по описанию версий элементов проекта можно при помощи атрибутов.

Атрибут позволяет давать дополнительные описания к версии элемента, к уже существующим комментариям. Например, удобно в качестве дополнительных полей держать атрибуты «warnings» и «errors», которые будут описывать числовые значения, выдаваемые компилятором при компиляции той или иной версии. Во время просмотра дерева историй версий, все атрибуты, связанные с ней (бесконечное число) отображаются наравне с именами меток. Особое значение атрибуты приобретают и при тестировании, если нужно пометить нулем или единицей протестированную версию, то создают атрибут «tested», и соответствующим образом «нумеруют» протестированные версии.

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

На рисунке 6 показан вид окна с атрибутами.

Для создания атрибута ему дают имя и тип данных, которые будут храниться.

Существуют следующие предопределенные типы значений:

Integer. Целое числовое значение. Подходит для большинства применений;

Real. Число с плавающей точкой. Подходит для глубокой нумерации версий;

Time. Временное описание;

String. Дополнительное символьное описание. Используется в тех случаях, когда одного комментария для описания версии недостаточно, например, для выделения протестированной версии можно просто создать атрибут «tested», а в качестве параметров давать значения «да» или «нет»;

Opaque. Произвольный тип значения. Используется в тех случаях, когда тип значения неизвестен изначально (таких ситуаций лучше избегать).

Для типов значений Integer, Real и Time можно задать ограничитель значений (ограничить диапазон вводимых значений).

Для всех типов значений возможно включение пункта «enumeration», для внесения предустановленных значений (например, только 0 и 1 для атрибута тестирования, или «да» и «нет» для него же).

Также удобно пользоваться пунктом default value, устанавливающим начальные значения для атрибута, например, число ошибок (errors) и предупреждений (warnings) по умолчанию, равняется нулю.

Работа из командной строки

Ниже приведен список команд, на которые необходимо обратить внимание, для управления типами атрибутов:

Mkattype. Создание типа атрибута;

Mkattr. Назначение типа атрибута конкретной версии элемента;

Rmattr. Удаление типов объектов;

Lstype. Просмотр типов объектов;

Describe. Просмотр свойств объектов.

Типы гиперссылок

Hyperlink type

clip_image026

Гиперссылки осуществляют логическую связь двух и более объектов под определенным именем.

Необходимость в наличии гиперссылок связана с тем, что в проектах очень часто бывает необходимым проставить связи между объектами, или между различными версиями различных объектов. Например, таким образом можно соединять зависимые объекты или данные. ClearCase сам использует механизм гиперссылок для таких операций, как слияние (merge) или работами с базовыми линиями, или для указания иерархии репозиториев (PVOB и компонентный VOB).

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

Бывают следующие типы гиперссылок:

Двунаправленные (bidirectional). Соединяет между собой два объекта в пределах одного или нескольких VOB. Полученная связь имеет направление, и соответствующим образом отображается («ИЗ» à «В» или же «В» à «ИЗ»);

Однонаправленные (unidirectional). Полученная связь в формате «ИЗ» à «В», вместе с которой дается текстовая аннотация, используемой в качестве завершающего в цепочке связей;

Текстовые (text-only). Данный вид связи как правило используется, для объединения данных репозитория с «внешним миром». При помощи текстовых связей можно связать алгоритм, находящийся в версии элемента с документом, в котором он был описан;

Висячие (null-ended). Подразумевает только исходящую связь от объекта, ни к чему не привязанную.

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

Иногда возможно непроизвольное создание связей, например, при слиянии версий образуется связь merge (двунаправленная).

Работа из командной строки

Ниже приведен список команд, на которые необходимо обратить внимание, для управления типами гиперссылками:

Mkhltype. Создание типа гиперссылки;

Mkhlink. Назначение типа гиперссылки конкретной версии элемента;

Rmhlink. Удаление гиперссылки;

Lstype. Просмотр типов объектов;

Describe. Просмотр свойств объектов.

Типы триггеров

Trigger Type

clip_image028

Из всех метаданных, пожалуй, самый неоднозначный тип. Если говорить об определении слова «Триггер», то это пользовательский обработчик событий, который дополняет или подменяет стандартный обработчик, придавая тем самым, продукту новую функциональность. Расширив ClearCase триггерами, возможно, добиться от продукта любой функциональности, которая не была предусмотрена создателями пакета.

ClearCase являет собой событийно-ориентированной системой, то есть все действия пользователя над данными приводят к генерации системного события, на которое в свое время, можно поставить обработчик.

Рассмотрим схематически событийность ClearCase. Рисунок 6 демонстрирует принципиальную схему события, его обработки и реакции.

clip_image029

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

Пользовательские триггеры в ClearCase делятся на два типа «pre-op» и «post-op»:

pre-op. Предоперационный тип триггеров. Данный вид, встраивается перед стандартным обработчиком и выполняет оперделенные действия. Мощная часть pre-op заключается в том, что стандартный обработчик на входе анализирует код возврата, и если код возврата отличен от нуля, то обработка сценария по стандартной схеме не будет производиться. Получается, что данный тип триггеров способен проводить различный запретительные операции. Например, в интересах корпоративной политики, разработчиков и тестировщиков нужно обязать комментировать действия check-in и check-out (СС в обычных настройках только полагает, что пользователь ввел комментарий, но не проверяет этого) для получения обширной картины истории редактирования элемента. Для этого создается pre-op скрипт, анализирующий число символов в поле комментария, и в том случае если оно равно 0, вывести на экран сообщение об ошибке и вернуть -1. Стандартный обработчик не вызовется, и пользователь будет вынужден повторить комментирование.

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

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

В качестве обработчика может выступать любой бинарный или пакетный файл, то есть реализовать триггер можно на любой языковой системе от Pascal до C#. Но наиболее оптимальным шагом будет использование интерпретатора языка Perl, который входит в состав Rational ClearCase. Во-первых, для целей работы со строками данных (это большинство данных) он подходит наилучшим образом, во-вторых, срок и стоимость реализации данного вида скриптов существенно ниже (не нужно компилировать), и в-третьих, скрипты, созданные на perl одинаково правильно работают на любых операционных системах (имеется в виду использование смешанной среды Windows и Unix).

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

Триггер можно поставить на тип элемента, например, только на элемент binary_deltа, или на отдельный файл или директорию (а также на группу файлов и директорий).

Также следует отметить, что количество триггеров, ставящихся на один тип события, ничем не ограничено.

Реализация скриптов

Рассмотрим триггеры более подробно. Обработчики можно ставить только на определенные события. К сожалению, не все события, имеющиеся в ClearCase позволяют взаимодействовать с системой триггеров. Ниже приведен список основных событий, на которые можно поставить дополнительный обработчик:

uncheckout Отказ от внесения новой версии в проект;

unreserve Нерезервное редактирование;

checkin Внесение изменений под контроль (регистрация версии);

chtype Изменение типа выбранного элемента;

lock Установка замка на версии элементов (или элемент в целом);

mkbranch Создание ответвления;

mkelem Создание элемента;

rmbranch Удаление бренча;

rmelem Удаление элемента;

rmver Удаление версии из вида;

unlock Снятие блокировки с элемента;

mkattr Назначение атрибута на версию элемента;

mkhlink Назначение гиперссылки;

mklabel Назначение предопределенной метки на версию элемента;

mktrigger Создание триггера;

rmattr Удаление атрибута;

rmhlink Удаление гиперссылки;

rmlabel Удаление метки;

rmtrigger Удаление триггера;

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

На каждое из этих событий можно поставить триггер pre-op и post-op.

При возникновении события, ClearCase определяет переменные среды и передает их обработчику (триггер их может перехватить, и при желании изменить. Если это pre-op триггер, после которого следует стандартный обработчик. Тем самым мы можем воздействовать и на него).

Передаются следующие переменные среды события:

%CLEARCASE_USER%. Имя пользователя, инициировавшего событие (берется системное имя, под которым был проведено «логин» в систему);

%CLEARCASE_PN%. Полный путь до элемента, над которой проводятся действия. Полный путь подразумевает не только описание иерархии каталогов, но и описание версии элемента в нотации MVFS (например, z:\develop\1.cpp@@\main\3);

%CLEARCASE_PN2%. Упрощенный путь. Указывается только путь до файла;

%CLEARCASE_BRTYPE%. Тип бренча, на котором было порождено событие.

%CLEARCASE_COMMENT%. Комментарий, которым сопровождалось событие;

%CLEARCASE_ELTYPE%. Тип элемента, на котором произошло событие;

%CLEARCASE_HLTYPE%. Тип гиперссылки элемента (если таковая была);

%CLEARCASE_LBTYPE%. Тип метки;

%CLEARCASE_OUT_PN%. Результирующий путь (данное поле заполняется в случае операции merge, когда необходимо указать источник и приемник);

%CLEARCASE_OP_KIND%. Наименование операции события. Именуется простым текстом;

Разные события по-разному заполняют переменные среды. На это следует обратить особое внимание. Если событие не заполняет поле, то поле имеет пустой значение (нулевое).

За основу языка скриптов мы берем язык Perl (причины подобного выбора оговариваются выше).

Попробуем рассмотреть несколько простых примеров скриптов-обработчиков.

Пример 1. Запретительный скрипт («pre-op»), не позволяющий проводить операцию checkout пользователю «ivanov»:

###########

if($ENV{CLEARCASE_COMMENT}=~»ivanov»)# Проверяем пользователя

{

$ent = system(«clearprompt yes_no -prompt \»Нельзя!\» -mask abort -prefer_gui «);

#при помощи специальной инструкции ClearCase выводим сообщение об ошибке

exit(-1); # делаем код возврата -1. Стандартный обработчик его воспримет и
# не будет запускаться

}

###########

Скрипт не оговаривает (и не должен оговаривать) тип элементов и операций, на которых он вызывается. Эти параметры устанавливаются на этапе создания триггера.

Пример 2. Демонстрационный пример. Скрипт можно ставить на любое событие как post-op. Его работа заключается в сборе любой информации о элементе, с записью в файл:

###########

open(ALEX, «>c:\Alex1.log»); #Открываем файл для записи

#Записываем в открытый файл комментарии и полученные значения переменных среды

print ALEX «CLEARCASE_USER — «;print ALEX $ENV{CLEARCASE_USER};print ALEX «\n»;

print ALEX «CLEARCASE_PN — «;print ALEX $ENV{CLEARCASE_PN};print ALEX «\n»;

print ALEX «CLEARCASE_BRTYPE — «;print ALEX $ENV{CLEARCASE_BRTYPE};print ALEX «\n»;

print ALEX «CLEARCASE_COMMENT- «;print ALEX $ENV{CLEARCASE_COMMENT};print ALEX «\n»;

print ALEX «CLEARCASE_ELTYPE — «;print ALEX $ENV{CLEARCASE_ELTYPE};print ALEX «\n»;

print ALEX «CLEARCASE_HLTYPE — «;print ALEX $ENV{CLEARCASE_HLTYPE};print ALEX «\n»;

print ALEX «CLEARCASE_LBTYPE — «;print ALEX $ENV{CLEARCASE_LBTYPE};print ALEX «\n»;

print ALEX «CLEARCASE_OUT_PN — «;print ALEX $ENV{CLEARCASE_OUT_PN};print ALEX «\n»;

print ALEX «CLEARCASE_PN2 — «;print ALEX $ENV{CLEARCASE_PN2};print ALEX «\n»;

print ALEX «CLEARCASE_OP_KIND- «;print ALEX $ENV{CLEARCASE_OP_KIND};print ALEX «\n»;

print ALEX «CLEARCASE_MTYPE — «;print ALEX $ENV{CLEARCASE_MTYPE};print ALEX «\n»;

#Отдельной строкой (строками) применяем команду описания элемента(describe)

open (DESC, «cleartool desc -l $ENV{CLEARCASE_PN} |»);

while( <DESC> ) {

chomp;

@_ = split;

print ALEX «@_ \n»;

}

#Применяем команду описания истории правок элемента

open (DESC, «cleartool lshis $ENV{CLEARCASE_PN} |»);

while( <DESC> ) {

chomp;

@_ = split;

print ALEX «@_ \n»;

}

#Смотрим дерево версий

open (DESC, «cleartool lsvtree -a $ENV{CLEARCASE_PN} |»);

while( <DESC> ) {

chomp;

@_ = split;

print ALEX «@_ \n»;

}

#Закрываем все дескрипторы

close (ALEX);

close (DESC);

#Полученный текстовый файл выводим на экран через notepad

$ent = system(«notepad.exe c:\Alex1.log»);

###########

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

Рисунок 7 показывает фрагмент экрана, с появившемся Notepad после события check-out.

clip_image031

Обратите внимание, окно с Notepad содержит историю редактирования элемента, с комментариями к каждому изменению номера версии.

Разработка корпоративного стандарта на триггеры

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

Для четкого контроля над проектом просто необходимо выработать ряд правил, в соответствии с которыми все участники проекта будут вести разработку. Сюда входят такие важные стандарты, как формирование базовых линий, формирование отчетов, продвижения базовых линий… и так далее. Но все эти стандарты уже описаны с той или иной степень детальности в Rational Unified Process, а их поддержка встроена в ClearCase. Триггеры же позволяют сделать политику еще более строгой, и гибкой в управлении.

Рассмотрим простой пример корпоративного стандарта – лист разрешений на работу пользователей. Он представляет собой текстовый файл, в котором описаны все участники проекта и их права на выполнение отдельных команд. Например, всем пользователям кроме администраторов и менеджер нужно запретить выполнять любые деструктивные операции (удаление элемента, удаление версии, перемещение…). Также нужно ограничить круг лиц, которые могут создавать новые типы данных (элементы, метки, триггеры). В дополнение, необходимо очертить круг лиц, которые будут создавать базовые линии и проводить операции слияния версий в основной проект. Все подобные действия создаются путем создания триггеров на указанные операции. Те, в свою очередь, сверяются с заранее подготовленным списком пользователей и его правами. В случае совпадения желаний участника с его правами, команда будет исполнена (запретительный триггер pre-op).

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

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

Также при помощи триггеров можно осуществить и шифрование данных и их автоматическое сжатие (особенно важно при хранении бинарных файлов в больших объемах).

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

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

Работа из командной строки

Ниже приведен список команд, на которые необходимо обратить внимание, для управления типами атрибутов:

Mktrtype. Создание типа триггера;

Mktrigger. Назначение типа триггера конкретному элементу;

Rmtrigger. Удаление типа триггера;

Lstype. Просмотр типов объектов;

Describe. Просмотр свойств объектов.

Управление метаданными репозиториев в IBM Rational ClearCase, 10.0 out of 10 based on 1 rating

Связные и просто интересные записи:

Метки:clearcase, ibm, rational, уи, УК, управление конфигурациями

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam protection by WP Captcha-Free