Статьи

Данный раздел содержит статьи по программной инженерии, отечественным и зарубежным стандартам и методологиям, а также инструментальным средствам IBM Rational, Microsoft, Jira, Subversion.
Все статьи единым списком -->

 

Портфолио

Специалисты СМ-Консалт:

Наша компания является бизнес-партнером IBM и Microsoft и имеет статус Advanced IBM Partner.
Среди специалистов компании только сертифицированные профессионалы и эксперты, чей опыт и знания не вызывают сомнений.Нами выполнены и выполняются сложнейшие проекты и очень внимательно подходят к проблематике заказчика. За нашими плечами более 20 успешных проектов.За годы работы нами наработаны УНИКАЛЬНЫЕ решения, расширяющие и дополняющие инструментальные средства IBM Rational , что не раз помогало нашим клиентам решать самые сложные задачи.
Данный раздел содержит Резюме наших специалистов и их квалификацию и опыт работы, перечень наиболее значимых проектов, с отзывами заказчиков.


Конфигурационное управление на основе Rational ClearCase

Оглавление

Оглавление 2

5

Конфигурационное управление и управление изменениями в RUP. 6

Введение 6

Цель: 8

Одновременное обновление 8

Ограниченное уведомление 8

Множественные версии 8

Связь с другими этапами работ 9

Концепции 10

Управление Конфигурацией и Запросами на Изменения 10

Структура Каталога Продукта (Product Directory Structure) 13

Управление Запросами на Изменения 13

Определения 14

Управление базовыми линиями 20

Метод продвижения базовых линий 21

Отчет о статусе конфигурации 22

Рабочие пространства (Workspaces) 23

Рабочие конфигурации 24

Просмотры (виды) 24

Методологическая и инструментальная поддержка конфигурационного управления и управления изменениями 25

Базовый: 25

UCM: 26

Этапы работ при конфигурационном управлении 27

Создание проекта и среды 29

Изменение и продвижение конфигурационных элементов 30

Составление отчетов по конфигурационному пространству 31

Управление запросами на изменения 31

Роли участников проекта 32

Менеджер по конфигурационному управлению 32

Менеджер по Контролю за Изменениями 32

Интегратор 32

Любая роль (остальные участники проекта) 33

Соответствие RUP и CMM в плоскости конфигурационного управления 34

Введение в базовый ClearCase 42

На чем основан базовый ClearCase 44

Виды 47

Версионность в ClearCase 48

Деревья (branches) 48

Базовые линии 49

Особенности создания видов 52

Управление Унифицированными Изменениями 60

Рис.2 66

Рис.5 67

Метаданные VOB 71

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

Element Type 73

Типы меток 80

Label Type 80

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

Branch Type 84

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

Attribute type 88

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

Hyperlink type 91

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

Trigger Type 93

Общие принципы работы с командной строкой в ClearCase 102

Язык запросов 105

Язык аннотирования и форматного вывода 108

Основные команды командного интерпретатора cleartool 111

annotate 111

catcs 111

cd 111

checkin 112

checkout 112

checkvob 112

chevent 113

сhstream 113

chtype 113

cptype 115

deliver 115

describe 115

diff 116

diffcr 117

edcs 117

find 117

findmerge 118

fix_prot 118

get 119

ln 119

lock 119

ls 120

lsco 120

lsdo 120

lshis 121

lslock 121

lspriv 121

lsreg 122

lsreplica 122

lstype 122

lsview 122

lsvob 123

lsvtree 123

merge 123

mkactivity 124

mkattype 124

mkattr 124

mkbl 125

mkbrtype 125

mkbranch 125

mkcomp 126

mkdir 126

mkeltype 126

mkelem 127

mkhltype 127

mkhlink 127

mklbtype 128

mklabel 128

mkproject 129

mkregion 129

mstream 129

mktag 130

mktrtype 130

mktrigger 131

mkview 131

mkvob 131

mount 132

Mv 132

protect 132

pwd 133

pwv 133

rebase 133

reformatview 133

reformatvob 133

register 134

relocate 134

rename 134

reserve 134

rgy_passwd 135

rmattr 135

rmbranch 135

rmelem 135

rmhlink 136

rmlabel 136

rmmerge 136

rmname 136

rmregion 137

rmtag 137

rmtrigger 137

rmtype 137

rmver 138

rmview 138

rmvob 139

schedule 139

setactivity 140

setcs 140

umount 140

uncheckout 140

unlock 141

unreserve 141

update 141

Обоснование использования командной строки 142

Управление действиями, выполняемыми по расписанию 143

Управление сборкой и аудитом. 143

Использование SoDA 147

Использование встроенной системы с сохранением в виде Html 148

Использование командной строки для формирования элементарных отчетов 150

Использование языка скриптов для создания сложных форм отчетов 152

Планирование расписаний 162

Планирование расписаний из GUI 162

Планирование расписаний из командной строки 165

Конфигурационное управление и управление изменениями в RUP.



Введение


Основная задача конфигурационного управления ПО — установление и поддержание целостности проектных данных на протяжении всего жизненного цикла развития проекта.

Конфигурационное управление участвует в идентификации конфигурации выпускаемого ПО (то есть в выборе программного продукта и в его описании) в срок. SCM (Source Configuration Management) обеспечивает систематизированное управление изменениями конфигурации, поддержание их целостности и актуальности на протяжении всего жизненного цикла проекта. Результаты разработки, которые поставляются клиенту, находятся под управлением конфигурационной системы.

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

Конфигурационное управление RUP носит настолько четкий характер, что практически полностью ложится на модель качества Capability Maturity Model, касающуюся конфигурационного управления. Соответственно, RUP полностью обеспечивает качественное управление процессом КУ и может служить руководством к действию для всех, кто желает привести процессы в порядок, сделав их зрелыми по качеству, в соответствии с СММ.

Все данные из ключевых областей процесса (Key Process Area) охватывают возможные методы исполнения функции конфигурационного управления. В СММ все качественные требования представляются именно как KPA. Каждый из этих методов четко описывает определенный участок с формализованными требованиями, а RUP способен привести этот участок в соответствие означенному требованию.

Механизмы, идентифицирующие определенные элементы конфигурации, содержатся в KPA и описывают их развитие и сопровождение (исходные тексты, картинки, документация и пр.).

Ниже приведены основные постулаты конфигурационного управления:

Для реализации тех или иных действий, связанных с конфигурационным управлением, в RUP имеются несколько взаимосвязанных программных продуктов: Rational ClearCase (средство версионного управления), Rational ClearQuest (средство организации конфигурационного управления и управления изменениями). Также на некоторых этапах удобно использовать систему генерации проектной документации Rational SoDA для получения отчетов установленного образца. Для объединения регионально удаленных команд применяется приложение Rational ClearCase MultiSite.

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

Многие компании, не использующие КУ, сталкиваются с проблемой невозможности эффективного внесения изменений в ранние версии проектов по просьбе заказчиков. Например, в компании, разрабатывающей специальное ПО может быть множество версий (1.0, 2.0…, 10.0), а попросить внести изменения может заказчик, использующий ранние версии.

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

Конфигурационное Управление по Rational Unified Process с использованием позволит описанные действия проводить с максимальной эффективностью и в кратчайшие сроки. В дополнении к сказанному КУ по RUP включает:



Цель:

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


  1. Одновременное обновление (Simultaneous Update);

  1. Ограниченное уведомление (Limited Notification);

  1. Множественные версии (Multiple Versions);



Одновременное обновление

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


Ограниченное уведомление

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


Множественные версии

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


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

Система управления конфигурациями обеспечивает следующие преимущества:


  1. Поддерживает любые методы разработки и процессы. Является гибко настраиваемой;

  2. Сохраняет целостность продукта на протяжении всего жизненного цикла;

  3. Гарантирует полноту и корректность конфигурируемого продукта;

  4. Предоставляет устойчивую и наращиваемую среду для разработки продукта;

  5. Ограничивает изменения артефактов в зависимости от политики проекта;

  6. Обеспечивает всем необходимым для организации строгой или мягкой политики контроля за изменениями;

  7. Обеспечивает контроль над тем когда, кем и почему был изменен артефакт;

  8. Обеспечивает возможностями по интеграции со средствами разработки;

  9. Поддерживает расширения, для улучшения функциональности.


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


Связь с другими этапами работ

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

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

Отметим основные хранимые артефакты:

Модели Rational Rose;

Требования RequisitePro (включая шаблоны);

Отчеты SoDA (шаблоны отчетов и сами отчеты);

Артефакты разработки (исходные тексты, библиотеки, откомпилированные релизы);

Скрипты автоматизированного тестирования;

Любые артефакты, создаваемые в проекте.


Концепции


Управление Конфигурацией и Запросами на Изменения


Ниже перечислены главные аспекты Системы УК:


  1. Управление Запросами на Изменения;

  2. Отчет о статусе конфигурации;

  3. Управление Конфигурацией;

  4. Просмотр изменений;

  5. Выбор версии;

  6. Производство программного обеспечения;



Следующий Куб КУ отражает главные аспекты Системы УК.



Управление Запросами на Изменениятребует от инфраструктуры организации оценки стоимости и графика работ, связанных с изменениями, оценки влияния требуемого изменения на существующий продукт.


Учет конфигурационного статуса– используется для описания «состояния» продукта, основанного на типе, числе, частоте и серьезности обнаруженных дефектов, и исправленных в процессе разработки продукта. Полученные метрики являются полезными в определении общего статуса законченности проекта.


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


Просмотр изменений– описывает, что было сделано с компонентами, по какой причине, и когда. Он служит как история и объяснение изменений. Это надо отличать от оценки влияния предполагаемых изменений, как описывается при Управлении Запросами на Изменения.


Выбор версий Version Selection цель «выбора версий» заключается в том, что выбраны правильные версии элементов конфигурации для изменения или реализации.

Выбор версии основывается на «конфигурационной идентификации».

Производство программного обеспечения– при производстве программного обеспечение необходима автоматизация этапов компиляции, тестирования и изготовления программного обеспечения для распространения.



RUP описывает Систему УК, которая охватывает все аспекты УК. Эффективным процессом КУ может являться процесс, который:

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

  2. Помогает управлять развитием продуктов по разработке программного обеспечения;

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


Целью процесса КУ является упростить управление версиями артефактов привязанных к инструментарию разработки, избежать неэффективности производства документации.

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

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



Структура Каталога Продукта (Product Directory Structure)



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

В RUP артефакты сгруппированы и описаны в терминах этапов работ. Этими этапами являются:

  1. Бизнес Моделирование;

  2. Определение требований к системе;

  3. Анализ и дизайн;

  4. Реализация;

  5. Тестирование;

  6. Внедрение;

  7. Управление Конфигурацией и Изменениями;

  8. Управление Проектом;

  9. Настройка среды;



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

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


Управление Запросами на Изменения

Опишем основные моменты в управлении запросами на изменения:



Определения



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


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


Совещание КУИ по Пересмотру CCB Review Meeting – смысл этого совещания заключается в просмотре Представленных Запросов на Изменения. На совещании определяется обоснованность Запросов на Изменения. В случае если запрос обоснован, производится определение принадлежности изменения к текущей или другой версии. Определение основывается на приоритете, графике, ресурсах, уровне усилий, риске, серьезности и любого другого критерия определенного коллективом. Обычно во время совещаний КУИ обязательными его членами являются менеджер по Тестированию, менеджер по Разработке и представитель Маркетингового Отдела. Остальные участники приглашаются на встречу по мере необходимости.



Форма Регистрации Запроса на Изменения. Эта форма появляется, когда Запрос на Изменения впервые регистрируется. На форме отображаются только те поля, которые необходимо заполнить регистратору запроса. Внешний вид формы и ее логика должны быть подстраиваемыми под конкретный проект;

Объединенная Форма Запроса на Изменения. Данная форма отображается, когда Запрос на Изменения, который уже был зарегистрирован, пересматривается. Она содержит все необходимые для описания Запроса на Изменения поля.

Этап работ, связанный с Запросами на Изменения, описан в Деятельности: Установка Процесса Управления Изменениями.


Запрос на изменение на протяжении жизненного цикла меняет свой статус. Статус служит для точного описания текущего состояния запроса. Отметим основные статусы с поправкой на то, что их число может меняться в зависимости от корпоративной политики управления изменениями:



Состояние

Определение

Управление доступом

Submitted


Зарегистрирован

Это состояние появляется как результат: 1)регистрации нового запроса;

2)обновления существующего;

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

Все пользователи

Postponed


Отложен

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

Администратор

Менеджер проекта


Duplicate


Дублирован

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

Администратор

Менеджер проекта

Разработчик

Rejected


Отклонен

Запрос в этом состоянии определяется на совещании КУИ или назначенным лицом на предмет: обоснован он или требуется более детальная информация от регистратора. Если запрос уже открыт, то он удаляется из очереди запросов с резолюциями и в дальнейшем снова будет пересмотрен.

Для этого назначается отдельный член КУИ. От регистратора не требуется предпринимать какие-либо действия без крайней необходимости, в этом случае состояние запроса поменяется на More Info и он будет снова пересмотрен на совещании КУИ при появлении новой информации.

Администратор

Менеджер проекта

Менеджер разработки

Менеджер по тестированию

More Info


Дополнительная информация

Существует недостаточно данных для подтверждения обоснованности отклонения или дублирования запроса.

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

Администратор

Opened

Открыт

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

Администратор

Менеджер проекта

Менеджер разработки


Assigned


Назначен

За открытий запрос отвечает Менеджер Проекта. Он назначает работников в соответствие с типом запроса и изменяет график работ и прочее.


Менеджер проекта

Resolved


Разрешен

Означает, что разрешение этого запроса завершено и сейчас он готов для проверки.

Администратор

Менеджер проекта

Менеджер разработки

Отдел разработчиков

Test Failed


Не прошел тестирование

В данное состояние переводится запрос не прошедший тест или в отладочной сборке или в сборке версии. Его владелец автоматически изменяется на члена коллектива, который разрешил запрос.

Администратор


Verified


Проверен

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

Администратор


Closed


Закрыт

Запрос больше не принимается во внимание. Только Администратор КУИ имеет право закрыть запрос. Если регистратор желает оспорить закрытие ЗИ, ЗИ должен быть обновлен и перерегистрирован КУИ.

Администратор


Запросов на изменение может быть очень много, они могут описывать любые проектные изменения. Как частность, относящаяся к данному тому книги – управление ошибками или дефект трекинг.

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

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


  1. Начальный (зарегистрирован). Вводится человеком, который обнаружил ошибку. Здесь следует отметить, что ошибку может представить любой участник проекта. Это может быть служба технической поддержки, которая принимает нарекания по телефону, и должна как-то документировать свою деятельность. При помощи специальных механизмов, встроенных в CQ, представить ошибку может и сам заказчик (например, через Web-доступ). Еще, как вариант, можно встроить в конечный программный продукт "обратную связь" через электронную почту, когда найденный дефект в работе автоматически (по согласованию с пользователем) отправляется на сервер дефектов, где входит в состав базы дефектов.


  1. Назначено. В RUP предполагается наличие роли, действием которой, является просмотр и назначение представленных дефектов на конкретного исполнителя. Обычно это руководитель группы разработчиков или тестировщиков.


  1. Открыто. Данный статус начинается с момента реализации (редактирования) исполнителем ошибки. При этом, если говорить о связи CQ с ClearCase, можно отметить, что в базе CQ будет отражено имя файла (или файлов), номер версии и имя разработчика, который начал исправление дефекта. Это очень интересный момент, так как работа над одной ошибкой часто приводит к изменению в нескольких файлах исходного текста;


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


5. Протестировано. Это состояние свидетельствует о том, что версия протестирована. При совместной работе CQ и CC каждую версию сопровождает атрибут, на основании которого строится следующий релиз (продвигается базовая линия). Для того чтобы получить релиз, тестировщик помечает исправленную версию (ставит атрибут "tested"). Интегратор, просматривая атрибуты, делает новый релиз на основе проставленной метки.


6. Закрыто. Финальный этап. Отмечается после отправки версии клиенту.



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


Управление базовыми линиями


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


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

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


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


Существует несколько преимуществ при создании базовых линий:


1. Базовая линия является стабильной, не редактируемой точкой разработанных артефактов;

2. Базовая линия является отправной точкой, с которой может быть создан новый проект;

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

4. Базовая линия обеспечивает коллективу разработчиков способ для отката;

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


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

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



Метод продвижения базовых линий


По мере выполнения проекта качество и стабильность базовой линии улучшаются. Уровень продвижения – это атрибут базовой линии, который используется для оценки ее качества или стабильности. Атрибуты и уровни базовой линии могут быть определены в проекте, однако, некоторые примерные уровни продвижения таковы:


- Протестированная интеграция;

- Протестированная система;

- Протестированная принятие;

- Производство;


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


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


Отчет о статусе конфигурации

Учет конфигурационного статуса – используется для описания «состояния» продукта основанного на типе, числе, частоте появления и серьезности найденных и зафиксированных во время разработки продукта. Полученные метрики являются полезными при определении состояния завершенности проекта. На их основании выполняются продвижения БЛ.

Опишем основные источники отчетов:


Запрос на Изменение – основной термин для запроса на изменение артефакта или процесса. Основной процесс, связанный с ЗИ описан в Концепции: Управление Запросами на Изменения. Отчеты, основанные на ЗИ, могут быть отвергнуты по следующим категориям:

Отчеты по времени (Как долго различные ЗИ были открыты? Какова задержка между нахождением дефектов в версии и их исправлением?);

Распределение запросов по категориям (Численные отчеты);

Число запросов в категориях: по владельцу, приоритету, состоянию исправлены;

Тренд (Отчеты по времени и количеству);

Каково общее число ошибок найденных и исправленных за все время? Какова частота обнаружения и исправления ошибок? Каков «качественный промежуток» в терминах обнаруженных дефектов против исправленных? Каково среднее время исправления дефекта?


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


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


Носитель версии;

Листинги файлов. Их аннотирование;

Все уникальные данные (скрипты, отчеты);

Инструкции по инсталляции, а также любые продукты документирования;

Возможные проблемы и известные ошибки;


Ревизии. Существует два вида ревизий применяемых в УК:

Ревизия физической конфигурации;

Ревизия функциональной конфигурации;


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

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

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



Рабочие пространства (Workspaces)



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


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


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


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


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

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



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



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



Рабочие конфигурации

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


Просмотры (виды)

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




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

Существуют два типа видов: статичные слепки (snapshot) и динамические (Dynamic).

Более подробно о специфике видов читайте в соответствующей главе про ClearСase


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



Для поддержки конфигурационного управления разработаны специальные инструментальные средства, такие как Rational ClearCase – для версионного управления и Rational ClearQuest – управление изменениями. Каждый из инструментов может работать как отдельно, осуществляя лишь специфичную роль, так и совместно с другим.

Как для совместной, так и для индивидуальной работы инструментов созданы методологические рекомендации и средства их реализации. Всего существуют две методологии работы с конфигурационным управлением и управлением изменениями: Базовый (base) и UCM (Unified Change Management) Унифицированное Управление Изменениями.

UCM является надстройкой над базовой, с дополнительными функциями и дополнительными компонентами. Отметим основные достоинства и каждого:


Базовый:

Полный контроль над проектом;

Высокая степень морфируемости (то есть его можно подстроить под любую политику управления версиями);

Полная поддержка регионально удаленных команд.


UCM:

Быстрое управление версиями (не требуется тщательной проработки проекта);

Основывается на готовом стандарте управления версиями.




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


8. Унифицированное управление изменениями


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

Одним из основных аспектов модели UCM является то, что она унифицирует деятельности, используемые для планирования и просмотра состояния проекта и артефактов, подверженных изменению. Модель UCM реализована через процесс и инструментарий. Продукты Rational ClearCase и Rational ClearQuest являются основными технологиями UCM.

Этапы работ при конфигурационном управлении



Два первых этапа – административно-подготовительные, выполняющиеся единожды при формировании концепции проекта. Остальные этапы являются повторяемыми на протяжении жизненного цикла при разработке ПО.


Детали этапов работ.


Установка плана управления конфигурацией.



Цель:


Выработать стратегию управления конфигурацией проекта;

Выработать стратегию контроля за изменениями продукта;

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

Определить права и обязанности участников проекта;

Настроить политику ведения КУ (ограничить действия отдельных участников);

Описать стратегию в плане управления конфигурацией (включенного в план разработки ПО).



Стратегия КУ определяет способность к обнаружению, гарантии сохранности и формирования отчетности по артефактам, утвержденным для использования в проекте. Обнаружение (идентификация) достигается путем надлежащей фиксации действий. Сохранность артефактов проекта достигается через архивацию, установку базовых линий и ведение отчетов. Здесь выбирается политика построения отчетов: автоматическая или ручная.

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

Немаловажный момент в планировании КУ можно считать применение e-mail нотификаций, для оповещения заинтересованных групп (как правило руководящих) о тех или иных действиях сотрудников (например, после операций слияния менеджер проекта получает письмо в котором говорится, кто, с какими данным произвел какую операцию).

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

План КУ описывает все виды деятельностей относящихся к УК, которые надлежит выполнить во время жизненного цикла продукта/проекта. Он описывает, как эти деятельности должны планироваться, выполняться, контролироваться и организовываться.


Создание проекта и среды

Цель:

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

Формируется каталог (древовидная структура каталогов);

Если проект был в другой версионной системе, то выбирается наиболее эффективный способ импорта;

Если проект располагался вне версионных систем (например, представлял файловую структуру на диске), то выбирается способ постановки данных под контроль с сохранением версионного дерева;

Пишутся скрипты, дополняющую политику КУ;

Расставляются permissions на элементы репозитория;

Выбирается количество репозиториев проекта и схема работы с ними: один основной и множество вспомогательных (в том числе, разбросанных на разных машинах), либо только один репозиторий;

Определяется внешний вид модулей СС и способ интеграции со средствами разработки;

Выбирается способ получения компилирующихся релизов и пишутся соответствующие скрипты.



Изменение и продвижение конфигурационных элементов



Цель:

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

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

Каждый из участников проекта может проводить локальную сборку, делая элементы компиляции общедоступными (derived objects);

Продвижение элементов зависит от вида КУ;



Управление базовыми линиями и релизами


Цель:


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


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

Процесс управления базовыми линиями также является зависимым от вида КУ (UCM или базовый);




Составление отчетов по конфигурационному пространству

Цель:

Определить, что продукт отвечает и функциональным и не функциональным требованиям;

Определить, что артефакты хранятся в контролируемой библиотеке;

Гарантировать, что артефакты и базовые линии доступны;

Поддержать деятельность по Учету Конфигурационного Статуса проекта, которая основана на формальных записях, отчетах по состоянию внесенных изменений и состоянию реализации предполагаемых изменений;

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

Гарантировать, что данные «свернуты» и описаны с целью отслеживания развития и тенденций;

Отчеты формируются автоматически или вручную, используются сторонние продукты (SoDA), или встроенные в СС возможности.



Управление запросами на изменения


Цель:


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


Роли участников проекта

Менеджер по конфигурационному управлению

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

Менеджер по конфигурационному управлению также ответственен за написание Плана КУ и формирования статистических отчетов, основанных на запросах на изменение.



Менеджер по конфигурационному управлению должен понимать принципы конфигурационного управления и предпочтительно иметь опыт в использовании инструментария Конфигурационного Управления. Хороший менеджер по конфигурационному управлению уделяет внимание деталям. Он/она должен гарантировать, что разработчики будут следовать процедуре конфигурационного управления.


Менеджер по Контролю за Изменениями

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

Менеджер по контролю за изменениями также отвечает за определение Процесса Контроля за Изменениями, который документируется в КУ Плане.



Интегратор

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

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


Любая роль (остальные участники проекта)

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



Соответствие RUP и CMM в плоскости конфигурационного управления


CMM (Capability Maturity Model) — модель зрелости процессов создания ПО, или эволюционная модель развития способности компании разрабатывать качественное программное обеспечение.

Изначально CMM разрабатывалась и развивалась как методика, позволяющая крупным правительственным организациям США выбирать наилучших поставщиков ПО. Для этого предполагалось создать исчерпывающее описание способов оценки процессов разработки ПО и методики их дальнейшего усовершенствования. В итоге авторам удалось достичь такой степени подробности и детализации, что стандарт оказался пригодным и для обычных компаний-разработчиков, стремящихся качественно улучшить существующие процессы разработки, привести их к определенным стандартам.

Ключевым понятием стандарта является зрелость организации. Незрелой считается организация, в которой процесс разработки программного обеспечения зависит только от конкретных исполнителей и менеджеров, а решения зачастую просто импровизируются «на ходу» — то, что на современном языке называется творческим подходом, или искусством. В этом случае велика вероятность превышения бюджета или выхода за рамки сроков сдачи проекта, поэтому менеджеры и разработчики вынуждены заниматься только разрешением актуальных проблем, становясь тем самым заложниками собственного программного продукта. К сожалению, на данном этапе развития находится большинство компаний (по градации CMM этот уровень обозначается числом 1). CMM определяет пять уровней зрелости организаций. В результате аттестации компании присваивается определенный уровень, который в дальнейшем может повышаться или понижаться (1 – начальный, 2 – повторяемый, 3 – определенный, 4 – управляемый, 5 – оптимизирующий).

Мы не будем рассматривать детально CMM, оставив это для более специализированных изданий. В данной части мы опишем только отношение СММ и конфигурационного управления по RUP.

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


Нижеприведенная таблица оговаривает ключи СММ, их соответствие ролям и процессам в Rational Unified Process.





Описание ключа

Роль в RUP

Процессы в RUP

Примечания

Сo1

Проект выполняется в соответствии с установленной организационной политикой (Software Configuration Management)

Инициативная группа

 

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

Ab1

Руководство обладает полномочиями для управления существующими или устанавливаемыми проектными базовыми линиями

Менеджер проекта, руководитель

Конфигурационное управление и управление версиями, план проекта конфигурационного и версионного контроля

Подразумевается определение конкретной политики версионного управления.

Ab2

Организуется работа группы, ответственной за  внедрение SCM для существующего проекта

Любой работник

Управление проектами. Разработка SDP (Software Development Plan)

Входящими данными для этого ключа могут служить: модель системы в Rational Rose, и сгенерированный на ее основе отчет в SoDA, по SDP.

Ab3

Выделяются ресурсы и финансирование для выполнения SCM-действий

Менеджер проекта

Управление проектами. Разработка SDP

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

Ab4

Все члены SCM-групп обучены  процедурам и методам для исполнения SCM-действий

Менеджер проекта

Управление проектами. Управление итерациями

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

Ab5

Члены группы разработки программного обеспечения связываются с обученными группами, чтобы дополнять их SCM-действия

Менеджер проекта

Управление проектами. Управление итерациями

То же, что и предыдущий шаг.

Ac1

План SCM готовится к каждому проекту согласно установленной процедуре

Менеджер конфигураций

Конфигурационное управление и управление версиями. План проекта конфигурационного и версионного контроля

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

Ac2

Зарегистрированный и утвержденный SCM-план используется в качестве основы для выполнения дальнейших SCM-действий

Менеджер конфигураций

Конфигурационное управление и управление версиями. План проекта конфигурационного и версионного контроля

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

Ac3

Система библиотек управления конфигурациями установлена как основа (репозитарий) для программных базовых линий

Менеджер конфигураций

Конфигурационное управление и управление версиями. Создается  конфигурационная среда

Администратор ClearCase и ClearQuest реализует физическое воплощение  запланированной конфигурационной политики. Создается репозитарий, насыщаемый элементами конфигурации. Определяется политика безопасности.

Ac4

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

Менеджер конфигураций

Конфигурационное управление и управление версиями. План проекта конфигурационного и версионного контроля

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

Ac5

Запросы на изменение и отчеты по всем элементам конфигурации должны быть введены, зарегистрированы, рассмотрены и одобрены согласно установленной процедуре

Менеджер проекта, руководитель

Конфигурационное управление и управление версиями. План проекта конфигурационного и версионного контроля

Данная функциональность может быть обеспечена при совместном использовании ClearCase и ClearQuest. При настройке выбирается тип возможной совместной работы продуктов: UCM или BASE. От выбранного типа существенно зависит политика дальнейшей работы.

Ac6

Изменения базовых линий управляются согласно установленной процедуре

Интегратор

Конфигурационное управление и управление версиями. Управление релизами и базовыми версиями

В зависимости от выбранной политики использования ClearCase (UCM или базовый) выбирается политика нумерации релизов.

Ac7

Базовые линии компилируются и  управляются согласно установленной процедуре

Интегратор

Конфигурационное управление и управление версиями. Управление релизами и базовыми версиями.

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

Ac8

Состояния элементов конфигурации и модулей зарегистрированы согласно установленной процедуре

Любой работник

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

Собственно процесс обеспечения доступа к подконтрольным данным любого участника.

Ac9

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

Менеджер конфигураций

Конфигурационное управление и управление изменениями. Мониторинг состояния и создания отчетов статуса конфигурации

Генерация отчетов возможна как через сам ClearCase, так и через специальные средства отчетности, такие как Rational SoDA. Если используются возможности ClearCase, то допускается автоматизированная генерация произвольных отчетов по заранее установленному расписанию.  

Ac10

Аудит базовых линий проводится согласно установленной процедуре

Менеджер конфигураций

Конфигурационное управление и управление изменениями. Мониторинг состояния и создания отчетов статуса конфигурации

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

Me1

Единицы измерения созданы и используются для определения состояний SCM-действий

Менеджер проектов

Управление проектом. Отслеживание и контроль проекта

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

Ve1

SCM-действия периодически просматриваются старшими менеджерами или руководителями

Рецензент проекта

Управление проектом. Отслеживание и контроль проекта

Все отчеты читаются и рецензируются.

Ve2

SCM-действия просматриваются в двух случаях: периодически и по событиям (действий)

Менеджер проектов

Управление проектом. Отслеживание и контроль проекта

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

Ve3

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

Менеджер конфигураций

Управление конфигурациями и изменениями. Отслеживание состояния и вывод отчетов по конфигурационному статусу

Периодически проводится аудит состояние проектных линий. Отчеты по базовым линиям представляются ClearCase. Группа ответственных лиц периодически просматривает, не противоречат ли они установленным ранее политикам.

Ve4

Группа гарантии качества ПО просматривает и/или проводит ревизию действий и генерирует соответствующие отчеты

Рецензент проекта

Управление проектом. Отслеживание и контроль проекта

 

Термины, используемые в таблице:

SCM — Software Configuration Management

SDP — Software Development Plan

SCMP — Software Configuration Management Plan

UCM — Unified Change Management

CM — Configuration Management

Введение в базовый ClearCase

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

ClearCase – инструментальное средство Rational Software для осуществления конфигурационного управления. СС является высокомасштабируемым средством клиент/сервер.

ClearCase отвечает за хранение и отслеживание всех артефактов проекта. Минимальная единица хранения информации в СС – это файл. Соответственно все манипуляции над проектом ориентированны именно на работу с файлами.

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

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

Посредством специальных видов разработчики и менеджеры могут следить за ходом изменений в реальном масштабе времени, получая нужные версии для редактирования и просмотра без дополнительной синхронизации с базой, что в разы увеличивает «поворотливость» больших систем, позволяя быстро переходить от версии к версии, от проекта к проекту. Реализовать этот уникальный подход позволяют виды (views), основанные на особой файловой системе MVFS (Multi Version File System), являющейся их неотъемлемой частью.

Помимо всех стандартных средств, присущих всем средствам версионного контроля, СС содержит в себе средства компиляции проектов, с сохранением среды перекомпилирования. Для компиляции поддерживается специальный подвид элементов, уникально управляемых ClearCase’ом. Сборка позволяет получить исполняемый (или любой другой) модуль для любой операционной системы и любым компилятором (от оригинальных компиляторов, компиляторов ms-dos и до любых современных на платформах windows\unix).

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

Для реализации всех возможностей ClearCase использует две методологии управления данными: «базовую» и UCM (Unified Change Management). Каждая из которых является эффективной в своем секторе.

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

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

В следующих главах мы будем рассматривать оба способа, но акцент все же будем ставить на базовый. Многие считают, что между UCM и «базовым» большая разница, вплоть до того, что это совершенно разные подходы. Нет, это не так! На 80% идеологии двух нотаций совпадают, соответственно, все базовые моменты, сказанные про «базовый» справедливы и для UCM, и наоборот. Разница в 20% и есть преимущество «базового» в области возможностей расширения. Раз так, то мы будем рассматривать общие принципы (детально рассматривать) и, ознакомительно, особенности. Сделано это в связи с тем, что совсем все описать не представляется возможным (просто материал, созданный к этому моменту сожжет потерять свою актуальность), да и не нужным, поскольку вся документация на все программные продукты Rational Software является общедоступной.

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

На чем основан базовый ClearCase

ClearCase представляет собой мульти модульное приложение. То есть для осуществления определенной функциональности используется не единая интегрированная среда, а совокупность множества исполняемых файлов. Все модули хранятся в директории \rational\clearcase\bin

Ссылки на модули находятся в меню «start». Помимо пунктов, СС допускает обращение к модулям из командной строки.

Для улучшения навигации по данным, СС предоставляет два навигатора: Clearhomebase и Rational ClearCase. Также для удобства использования, СС встраивается во все контекстные меню Windows, что позволяет пользоваться его функциями любым приложениям стандартно взаимодействующих с API Windows.

Врезка1

Врезка2







Рисунок 3. Пример интеграции ClearCase с Explorer’ом системы. Подобным образом интеграция происходит во всех модулях и приложениях Windows. Везде, где есть стандартное контекстное меню



Для реализации полного контроля над версиями в специальную базу данных - VOB (Version Object Base) - заносятся все изменения данных проекта.

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

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

Рисунок 5. Внешний вид закладки VOBS окна ClearCase details. Здесь расположены основные операции над VOB’ами. Исключение составляет операция удаления, выполняемая из командной строки администратором

Список репозиториев всегда можно получить, воспользовавшись кнопкой Mount VOB (рис. 5).

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

Второе понятие, на котором базируется работа с ClearCase – это ВИДЫ (Views).

Виды

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

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

Через систему видов выполняются абсолютно все операции, присущие не только ClearCase, но и любому другому средству версионного и конфигурационного контроля. К ним относятся такие команды как: начальная постановка данных под контроль (Add To Source Control), при котором для каждого элемента создается дерево версий, операции Check-in и Check-Out, позволяющие редактировать отдельный файл, создавая дерево версий, на котором отражена полная история развития отдельного элемента (рис. 5).



Рис. 6. История редактирования файла.



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

Dynamic view создают виртуальную файловую систему (MVFS), на которой размещаются все подконтрольные данные. Тем самым получается, что для клиента, обращение к серверу происходит через сетевой диск, то есть, также как при доступе к корпоративной сети. Исключительная особенность данных видов позволяет осуществлять контроль над файлами в реальном масштабе времени. То есть для работы с версиями файлов не нужно физически копировать их на локальные диск, подобно тому, как поступают практически все версионные системы. Динамические виды поддерживают хранение и обработку пользовательских (приватных) данных, не являющихся общедоступной частью проекта. И последнее, динамические виды позволяют проводить аудит данных и управляемую компиляцию (сборку). Система динамических видов одинаково работает на всех платформах, что позволяет вести проект, разрабатывающийся на разных семействах операционных систем. Причем вся работа будет происходить прозрачно.

Snapshot view оправдывает свое название, создавая "снимок" текущего состояния проекта на локальной машине. Разработчик получает на своем диске точную копию либо всего проекта, либо необходимой его части - файла, группы файлов: Важным моментом при такой работе является синхронизация локальных данных с общим проектом, которая в данном случае выполняется не автоматически, а по команде пользователя. Это делает возможной удаленную работу над проектом, позволяя любому разработчику взять материал "на дом", после чего вернуть новые версии файлов в проект. Данный способ обращения к базе используют подавляющее большинство версионных систем.



Версионность в ClearCase

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

Деревья (branches)

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

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

Из основных видов ответвлений можно отметить следующие:

BugFix – отладочные ветви для базовых линий проектов. Например, для базовой линии Rel1.0 можно создать отладочный Rel1.0BugFix

Development – основная ветвь, касающаяся основной ветви проекта

Integration – ветвь, в которую попадают все изменения, сделанные разработчиками

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



Базовые линии

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

Преимущества базовых линий очевидно: каждый официальный релиз проекта строится по базовой линии. История по всем базовым линиям хранится в репозитории. По мере необходимости можно взять за основу любую (даже самую старую) базовую линию (например, Rel1.0 или Release1.0) и построить на ее основе отладочный релиз Rel1.0BugFix. Изменения, внесенные в уже отладочный релиз, можно переместить на основную ветвь проекта (если он был протестирован и не содержал ошибок) и сделать новой базовой линией Rel1.1. В дальнейшем, уже на основе нового релиза можно создать отладочный Rel1.1BugFix.

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

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

Как и многие системы версионного управления, ClearCase позволяет проводить такие типичные операции как:

Слияние файлов и директорий;

Сравнение файлов и директорий;

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

Представление истории в древовидном виде.

Описанные функции являются стандартными для всех систем, ClearCase же дополнительно позволяет расширить эту функциональность в следующих направлениях:



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

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

Сравнение и слияние нескольких версий файлов, то есть, операцию можно проводить над любым количеством контрибуторов (см. командную строку: diff);

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



Версионное управление в СС осуществляется последовательным получением версий файлов, с постановкой атрибутов (для идентификации протестированных релизов). Метки релизов демонстрируют базовые линии. Менеджер КУ отвечает за продвижение базовых линий (создание новых, перемещение имеющихся). В случае необходимости создаются ветви для реализации отладки или переработки имеющихся базовых линий. Все разработчики работают в изолированных пространствах не мешая друг другу. Свои результаты «отдают» в то ответвление (тот поток) откуда брали данные для редактирования. Проводят компиляцию (автоматически или вручную). Полученные, в результате компиляции данные, специальными средствами делают общедоступными.

Подводя итог вводной части, отметим, что ClearCase имеет расширенные возможности по импорту (конвертации) данных из аналогичных систем версионного управления, таких как: CVS, PVCS, RCS, SCCS и SourceSafe. Для тех же кто не пользуется системами версионного управления, предусмотрены специальные механизмы, позволяющие создавать полноценные ClearCase – проекты, изымая исходные данные из поддиректорий проекта, размещенных на локальных дисках.

Быстрый старт

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

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

Рассмотрим сценарий дальнейших действий:

Создать структуру хранения информации;

Создать репозиторий;

Создать вид;

Поставить под управление элементы;

Сформировать базовую линию;

Сформировать отладочный на базе профиля;

Создать вид на основе профиля;

Получить базовые типы отчетов;

Провести изменения на основной ветви и на отладочной;

Сравнить версии;

Объединить версии;



Особенности создания видов

Итак, если вспомнить базовые возможности ClearCase в области хранения информации, то получается, что мы должны создать репозитарий (VOB), создать вид (один или несколько), затем любым известным способом копировать/сохранять файлы и директории на диск, созданный ClearCase, и установить за ними контроль (рис. 9).



Рис. 9. Здесь показан вид файла Alex.cpp, выведенного в состояние Check-Out. Скриншот сделан из текущего вида.

Здесь кроется определенная проблема: как организовать при этом совместный доступ к одному файлу и как будут поддерживаться разные версии и разные проекты? Это не праздные вопросы! Давайте посмотрим, что имеется в арсенале ClearCase для решения данных проблем. Но прежде хочу еще раз напомнить очень важный момент: ClearCase имеет свою особенную идеологию работы, которая не всегда понятна с первого взгляда, поскольку требует некоторого осмысления. Поэтому следует воздержаться от попыток "подмять" его под свои нужды. Скорее всего, это не получится, так как для получения наибольшей эффективности проще будет перестроить существующий подход - на тот, что предлагает ClearCase.

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



Рис. 10. Здесь показан вид файла , с другого компьютера.

Следует иметь в виду, что ClearCase имеет особую файловую систему - MVFS (MultiVersion File System), которая позволяет получать доступ к версии конкретного файла и производить его правку. Здесь необходимо учитывать, что при простом обращении к нужному файлу ClearCase предоставляет последнюю версию либо версию, находящуюся в состоянии Check-out (для разработчика, который взял файл на редактирование, ClearCase будет подставлять версию Check-out, для всех остальных участников - последнюю; рис. 9, рис. 10, рис. 11 и рис. 12 соответственно).



Рис 11. Так выглядит дерево версий для файла в текущем виде.

Рис 12. Так выглядит дерево версий для файла в текущем виде.

Такое положение приводит к тому, что каждый разработчик может взять один и тот же файл и заняться его доработкой: Но правильно ли это?

Ответ - НЕТ. Это неверно, поскольку после того, как разработчики закончат правку файла и дадут команду Check-in, ClearCase не сможет просто создать новую версию - ему придется вызвать MergeManager для объединения новой версии с существующей. А ведь разработчику следует как можно реже прибегать к данному модулю, чтобы не усложнять и без того непростую разработку программного обеспечения. Правда, выход есть и из такой ситуации.

Когда пользователь выводит файл в состояние редактирования (Check-out), ClearCase выводит окно, в котором просит ввести комментарий для события, а также то, каким образом файл будет представляться далее в проекте: RESERVED или UNRESERVED.

Состояние RESERVED превращает версию в зарезервированную за конкретным владельцем, и ClearCase не позволит другому пользователю сделать новую.

Состояние UNRESERVED позволяет всем участникам проекта создавать свои подверсии файла, но при этом самый "шустрый" пользователь, нажавший кнопку Check-in первым, устанавливает контроль за файлом как обычно, а остальным придется производить слияниe с новой версией (рис. 13).



Рис. 13. Так выглядит дерево в случае, если два пользователя одновременно ввели один и тот же файл в состояние Check-in. Как видим, сделать это можно, только стоит ли подменять работу одного человека работой другого?

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

Разумеется, ClearCase предлагает и более эффективные способы работы, правда, для их осуществления на практике необходимы некоторые знания.

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

element * CHECKEDOUT

element * /main/LATEST

Это значит: показать в виде все элементы в состоянии CHECKEDOUT или LATEST. Так происходит подстановка в виде файла с нужной версией в качестве файла по умолчанию.

Необходимость правки данного правила появляется, когда команде разработчиков требуется воспользоваться главным преимуществом ClearCase - параллельной разработкой, при которой каждый участник может создать свое ответвление на дереве версий и дорабатывать файл независимо от состояния проекта, чтобы в итоге объединить свою версию с основной. Менеджеру проекта также доступны преимущества параллельной разработки: во-первых, можно вести одновременно две версии различающихся файлов - с целью дальнейшего включения в другой проект, а во-вторых, по технологии Rational, решение о том, какие файлы с какими объединять, в итоге принимает не разработчик, а именно менеджер проекта.

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

Рассмотрим сначала построение видов на базе профилей.

Профили можно создавать сразу после инсталляции ClearCase в отдельно отведенный каталог, открытый для общего доступа. Здесь кроется основная проблема начинающих пользователей! ClearCase сам не создает каталоги и не настраивает свой доступ к ним - это приходится делать вручную. Путь к созданному каталогу (абсолютно пустому) прописывается на вкладке "Администрирование", как показано на рис. 14.



Рис. 14. Данная вкладка представляет собой часть окна администрирования.

После настройки путей становится полностью доступной вкладка Branches - ClearCase HomeBase (рис. 15).



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

При корректной установке можно смело нажимать на кнопку View Profile и создавать новый видовой профиль. Именовать его можно либо своим именем, либо по версии проекта (в зависимости от конкретной ситуации).

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

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



Рис. 16. Примерно так будет выглядеть дерево версий одного файла из Dev/View. Как видите, вторая версия файла была взята на доработку в разные проекты.

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

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



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



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

Мы рассмотрели самый простой способ создания видов. Если же разработчик (менеджер проекта) способен запомнить некоторые правила создания видов, то новые виды можно строить как угодно, меняя только правила просмотра. Если вид - это фильтр, то правило (Rule) - это своего рада маска для выбора. Не всегда нужно строить новый вид и создавать новый профиль для того, чтобы связать воедино несколько файлов, проще дать команду фильтрации по правилам.

По умолчанию ClearCase работает по правилу:

element * CHECKEDOUT

element * /main/LATEST

Это означает, что все файлы находятся в состоянии CHECKEDOUT либо это их последние версии.

Язык правил ClearCase достаточно прост. Как и многие другие операции, задание правил можно осуществлять как из пользовательского интерфейса, так и из командной строки. В последнем случае необходимо ознакомиться с командами "edcs" - редактирование записи для текущего или установленного вида, "catcs" - просмотреть текущее правило в текстовом режиме без возможности редактирования и "setcs" - установить новое правило, причем само правило необходимо оформить в виде отдельного файла, доступного всем участникам проекта, так, чтобы каждый из них мог ассоциировать свой вид с необходимым в данный момент правилом.

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

На основе правил проблема решается очень быстро! В процессе редактирования файлов каждый разработчик отмечал на дереве версий ту, которая считалась окончательной версией с соответствующим номером "REL1", "REL2", "REL3" и т.д. Для этого в ClearCase предусмотрен еще один механизм - механизм меток - простых, обыкновенных меток, знакомых всем с первых шагов в программировании. Разработчик вместе с менеджером проекта выбирают одну из версий на дереве и присваивают ей имя. В дальнейшем данная метка становится синонимом конкретной версии конкретного файла, то есть одну и ту же метку необходимо назначать разным файлам и разным подверсиям.

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

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



Рис. 19. Обратите внимание: первая версия для данного вида стала текущей, а самой версии назначено две метки (ClearCase позволяет поставить и больше - для тех случаев, когда одна и та же версия файла переходит из одного релиза в другой без изменений).

element * CHECKEDOUT

element * REL1

Можно, например, включить в фильтр все файлы с расширением BAT с нулевой версией, тогда правило будет иметь следующий вид:

element * CHECKEDOUT

element * REL1

element *.bat /main/0

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

element * CHECKEDOUT

element -eltype archive * REL1

Или просто отсортировать все файлы по дате или/и времени "...\bugfix\LATEST -time yesterday",

time 10-Jul.19:00 element \atria\lib\* ...\new\LATEST element * \main\LATEST end time

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

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

Разработчик может создавать различные ответвления версий своих файлов исключительно для собственного удобства, делая ответвления командой mkbranch, менеджер проекта совместно с разработчиком ставит метку с номером сборки проекта на конкретную версию. Если необходимо осуществить редактирование одного файла силами более одного человека, то прибегают к помощи MergeManager и профилей. А для создания сборок пишут правило ConfigSpec (Configuration Specification), по которому будут выводиться файлы.


Управление Унифицированными Изменениями

(Unified Change Management (UCM)



Управление Унифицированными Изменениями (UCM) – метод Rational Software для управления изменениями в системе разработки ПО, от постановки требований до выпуска релиза и его дальнейшей эксплуатации. UCM охватывает жизненный цикл разработки, определяя как управлять запросами на изменения, проектировать модели, документацию, компоненты, тестовые примеры и исходный код. Характерной чертой этой методологии является возможность управления изменениями на уровне задач вместо отслеживания изменений в отдельных артефактах.


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


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

П

Рабочее пространство UCM состоит из вида и потока. Вид - это дерево директорий, которое отображает одну версию каждого файла проекта. Поток - это объект, который поддерживает список действий (activities) и базовых линий и определяет версии элементов, появляющиеся в виде.

роект содержит одно общедоступное рабочее пространство (shared work area) и, обычно, несколько закрытых рабочих пространств (private work area). Закрытое рабочее пространство позволяет разработчикам работать над поставленными задачами независимо от остального коллектива разработчиков. Менеджер проекта и интегратор ответственны за поддержку общедоступного рабочего пространства.

Ниже перечислены основные этапы работ в UCM-проекте:

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

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

  3. Разработчики создают действия (activity) и работают над одним из них. Действие, как объект, является частью одного потока, и не может быть перемещено из одного потока в другой. Действие хранит информацию о наборе файлов, созданных или изменённых разработчиком в процессе выполнения поставленной задачи, такой как исправление ошибки. Этот набор файлов, связанный с действием, называют набором изменений (change set). Масштаб действий определяется менеджером проекта.

  4. Когда разработчики заканчивают действия, собирают и тестируют свою работу в закрытом пространстве, они делают результаты своей работы общедоступными для членов команды, выполняя операцию сдачи действия (deliver). Операция сдачи соединяет (merge) работу из закрытого пространтсва разработчика с работой из общедоступного рабочего пространства проекта.

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

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

  7. Периодически, при увеличении уровня качества и стабильности базовых линий, интегратор изменяет атрибут базовой линии – уровень продвижения (promotion level) – для отражения соответствующих этапов работы над базовыми линиями, такими как Собранная (Built), Протестированная (Tested), Сданная (Released). Когда новые базовые линии проходят через определённый этап тестирования, интегратор назначает их рекомендованным (recommended) набором базовых линий.

  8. Разработчики выполняют операции синхронизации (rebase) для обновления их закрытых рабочих пространств наборами версий, представленных в новых рекомендованных базовых линиях.

  9. Разработчики продолжают цикл работ над действиями, сдачей завершённых действий, обновлением их закрытого рабочего пространства новыми базовыми линиями.

Приведённый рисунок (рис. 1) иллюстрирует описанное взаимодействие циклов: управления проектом, разработки, интеграционного.

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

Управление проектом.

Под созданием проекта (Create project) подразумевается:

UCM включает набор политик (policies), которые можно установить для проекта, навязывая тем самым те или иные правила разработки коллективу проекта. Корректно сконфигурировав набор политик (establish policies), можно улучшить взаимоотношения в коллективе проекта и уменьшить возможные проблемы при слиянии сданных работ. Например, можно установить политику, требующую синхронизации рабочего пространства с последней рекомендованной базовой линией перед сдачей работы (deliver work).

Распределение и планирование работ (assign and schedule work) – дополнительная задача и имеет непосредственное инструментальное решение лишь при совместном использовании ClearCase и ClearQuest. В этом случае менеджер проекта выполняет распределение и планирование задач высокого уровня для команды, работающей над проектом. Возможен вариант, когда менеджер проекта создаёт действия (activities) и распределяет их по разработчикам.

Контроль за состоянием проекта (monitor project status) может проводиться менеджером проекта посредством следующих средств ClearCase:

Интеграционный цикл.

Создание потока для тестирования (create a testing stream). В UCM интегратор выполняет сборку сданных разработчиками работ, созданием базовых линий и тестированием их. При создании базовой линии в интеграционном потоке, необходимо блокировать этот поток для предотвращения сдачи разработчиками работ. Данный подход гарантирует работу с постоянным набором файлов при создании базовой линии. Но применять его можно лишь для быстрого тестирования базовой линии в интеграционном потоке, чтобы не создавать проблем для разработчиков со сдачей работ. Поэтому для выполнения более серьёзного тестирования, такого как регрессивное тестирование, необходимо создать поток разработчика и использовать его исключительно для тестирования базовых линий.

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

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

После того, как коллектив команды, следящий за качеством, провёл более тщательное тестирование новых базовых линий и определил, что они стабильны, базовые линии делаются рекомендованными базовыми линиями (recommend baselines). Тогда разработчики обновляют свои рабочие пространства новыми базовыми линиями, выполняя синхронизацию, сливая (merges) файлы и директории интеграционного потока со своими.

Цикл разработки.

Когда разработка ПО ведётся по UCM, то, как говорилось выше, работа любого разработчика представляет из себя циклический процесс.

Менеджер проекта создаёт UCM-объект, называемый проектом. Для доступа к исходным файлам проекта необходимо создать и настроить рабочие пространства (set up work areas). Поскольку разработчики изменяют исходные файлы, для правильной организации и идентификации их работы, они должны использовать действия (activities). Коллектив разработчиков не видит изменений проекта, сделанных отдельным членом, пока он не сдаст работу в общедоступное рабочее пространство. Периодически интегратор проекта объединяет действия в общедоступном рабочем пространстве посредством базовых линий. Этим базовым линиям присвоен набор действий (activities), отражающих значительные изменения в проекте. После создания новых базовых линий всем разработчикам необходимо синхронизировать своё рабочее пространство с действиями новых базовых линий.

Начало работы в UCM-проекте, фактически, означает присоединение разработчика к проекту (join a project) и конфигурирование рабочих пространств (каждый разработчик работает с двумя рабочими пространствами):

После конфигурирования рабочих пространств разработчику необходимо найти действия, которые менеджер проекта или друигие члены команды назначили ему. Либо создать самому новое действие. Поиск дейсвий осуществляется инструментальными средствами ClearCase, если действие уже установлено в рабочем пространстве разработчика. При использовании UCM-ClearQuest-интеграции, посредством специальных ClearQuest-запросов (таких как MyToDoList) можно найти действия, которые назначены конкретному разработчику, но ещё не установлены на его рабочее пространство. После того, как найдены действия, назначенные разработчику, необходимо установить вид разработчика на одно из этих действий (setting activities). Это означает, что ClearCase будет приписывать любые созданные версии файлов к набору изменений действия (activitys change set).

Следующий этап цикла работ называется работой над действиями (work on activities). Он включает в себя взятие файлов на редактирование (check out), изменение их и тестирование проделанных изменений. Также возможен вариант, когда разработчики обязаны вводить информацию в систему управления запросами на изменение для отображения прогресса их работы. Взятие файла на редактирование даёт возможность изменять его в виде разработчика. После того, как файл отредактирован, и разработчик считает нужным внести под контроль эту версию, делается соответствующая операция (check in). Но любая информация, внесённая под контроль, не доступна другим разработчикам до момента её сдачи. Собирать и тестировать работу в виде разработчика рекомендуется после синхронизации потока для избежания большого количества слияний во время сдачи.

Когда разработчик уверен, что действия можно делать общедоступными (этап работ - сдача действий – deliver activities) для команды проекта, он должен подготовить своё рабочее пространство для сдачи. В этом процессе можно выделить два основных момента:

После подготовки рабочего пространства разработчик может начинать непосредственно операцию сдачи (deliver activities). Как часть операции сдачи, ClearCase выполняет слияние работы в пространстве разработчика с работами в общедоступном рабочем пространстве. Если при этом произойдут конфликты слияния (merge conflicts), разработчик должен разрешить их. После разрешения конфликтов интеграционный вид содержит результаты слияний. Разработчику необходимо убедиться, что сданная им работа совместима с работами в общедоступном рабочем пространстве. Для этого разработчик должен собрать и протестировать файлы в интеграционном виде. При возникновении ошибок разработчик должен отредактировать файлы в общедоступном рабочем пространстве. Когда разработчик добился положительного результата при тестировании, он завершает операцию сдачи. ClearCase ставит под контроль изменения проекта и изменяет состояние потока разработчика.

Интегратор собирает сданные действия в базовые линии. Обычно базовые линии проходят через цикл тестирования и исправления ошибок для достижения удовлетворительного уровня стабильности. При достижении этого уровня интегратор назначает эту базовую линию рекомендованной базовой линией. Для того, чтобы разработчики работали с набором версий из рекомендованной базовой линии, они должны синхронизировать своё рабочее пространство (rebase work area). Для минимизации слияний при при сдаче работ разработчикам необходимо регулярно обновлять их рабочее пространство новыми базовыми линиями. После синхронизации необходимо собрать и протестировать исходные файлы в виде разработчика для того, чтобы несданные действия без ошибок собирались с версиями файлов из базовых линий.

Инструментальная реализация UCM в ClearCase.


Выше были рассмотрены основные моменты концепции UCM, теперь же, остановимся на реализации каждого этапа процесса разработки ПО в Rational ClearCase. Чтобы обратить внимание именно на выше перечисленные моменты при работе с Rational ClearCase в UCM, будем рассматривать простейшую команду, состоящую из менеджера проекта и разработчика. Функции интегратора будет выполнять менеджер проекта. Для наглядности проект будет вестись “с нуля” и представлять собой разработку самого обычного текстового файла “example.txt”.

Создание проекта.

С


Рис.2

Рис.3


Рис.4 Контекстное меню объекта pvob1 в Project Explorer.


оздание проекта в UCM начинается с создания репозиториев, в которых будет храниться вся информация о проекте, будь то сведения о потоках, действиях, наборах изменений или информация о видах, элементах. Для полноценного проекта в UCM необходимо минимум два VOB’а: проектный VOB (PVOB) и компонентный VOB. Инициировать процесс создания репозиториев можно при помощи утилиты ClearCase Home Base,а, именно, - пунктом “Create VOB”. В этом случае мастер поможет Вам корректно создать репозиторий. В первую очередь создаётся VOB проекта (PVOB), в котором будет храниться информация о UCM-объектах. Для этого в первом окне мастера необходимо поставить галочку в поле “Create as a UCM project VOB”, а галочку в поле “Create as a VOB level component” (создать VOB как компонент) надо убрать. Проектный VOB назовём pvob1 (фрагменты этого окна представлены на рис.2). В одном из следующих окон мастера для вновь создаваемого проектного VOB’а надо указать, что он не имеет административного репозитория (Рис.3). При создании же VOB’а, в котором будет храниться информация о файлах, директориях и других объектах компонента (компонентный VOB), в первом окне мастера галочки надо поставить абсолютно наоборот. Компонентный VOB назовём vob1. А в окне с вопросом, какой VOB будет административным для создаваемого репозитория, необходимо выбрать pvob1. После этого этапа у нас уже имеется как бы скелет для будущего проекта – место, где ClearCase будет хранить всю информацию. Осталось наполнить проектный VOB данными о проекте, который ещё не существует физически. Чтобы наполнить PVOB минимальным набором необходимых данных, надо запустить Project Explorer, и создать в PVOB’е проект. Делается это выбором в контекстном меню объекта pvob1 пункта New->Project (Рис.4).

В

Рис.5

этом случае мастер поможет Вам создать проект. (В рассматриваемом примере –
project1.) На третьем шаге мастера (New ProjectStep3) надо сконфигурировать в компоненте базовую линию: Add->vob1_initial. На четвёртом шаге мастера (New ProjectStep4) обязательно надо сделать компоненту изменяемой (Рис.5).

После завершения работы мастером, PVOB и VOB будут наполнены необходимыми данными для начала работы в рамках UCM. В частности, будет создан первый, и главный поток слияний. По умолчанию его имя <project_name>_integration. В нашем случае – project1_integration. Но для того, чтобы начать манипулировать данными в VOB’е, необходим вид. Первым надо создать вид интегратора. Затем из него мы поставим под контроль файлы, создадим новую базовую линию, содержащую эти файлы. Назначим её рекомендованной базовой линией. После этого уже можно создавать потоки разработчиков и наполнять их нужными файлами из рекомендованной базовой линии.


Итак, создадим вид интегратора. Инициировать этот процесс можно из Project Explorer’а. Для этого в контекстном меню объекта project1_integration надо выбрать пункт “Create View”. Опять же, запустится мастер, который уже знает, что Вы хотите создать вид интегратора. (Считаем, что все создаваемые виды – динамические. Потому что именно в этом случае можно использовать большинство удобных возможностей ClearCase, отличающих его от конкурентов).


Теперь создаём файл для постановки его под контроль. Делаем эту элементарную операцию, например, из утилиты ClearCase Explorer в виде интегратора (на диске MVFS). Поставить под контроль созданные файлы можно из этой же утилиты, воспользовавшись пунктом “Add to Source Control…” из контекстного меню созданного файла. В виду того, что ещё ни одно действие (activity) не было создано, то сразу же запускается мастер для создания действия, с которым будет ассоциироваться постановка под контроль файла. Назовём это действие для наглядности “add”. Для того, чтобы избавить себя от лишнего, в данном примере, выведения файлов на редактирование, - можно поставить галочку в поле “Checkout after adding to source control”. После окончания работы мастером, файл является уже элементом компонента, т.е. частью проекта. Не трудно видеть, что файл выведен на редактирование именно под действием – “add”. Теперь можно вносить изменения в файл, которые сохранятся на диске MVFS. После правки файла его необходимо записать в VOB, тем самым вывести из состояния редактирования. Это делается командой check in. Чтобы не возникло ошибки при операции “check in” с неизменённым файлом, в окне мастера надо поставить галочку в поле “Checkin even if identical”. После того как новый элемент зафиксирован в VOB’е, можно создавать рекомендованную базовую линию, содержащую этот файл (правильнее сказать – данную версию файла). Запустить соответствующего мастера можно из Project Explorer, выбрав в контекстном меню потока слияний пункт “Make Baseline”. На первой закладке первого окна можно изменить имя базовой линии, если у Вас уже есть система именования базовых линий (в данном примере эту базовую линию назовём BL1). На второй закладке этого окна можно посмотреть и выбрать нужные сданные действия, на основании которых построится базовая линия (в случае рассматриваемого примера – действие add). Для более “прозрачного“ наполнения новых потоков необходимыми файлами, необходимо созданной базовой линии назначить статус рекомендованной. Опять же, в контекстном меню потока project1_integration выбираем пункт Recommend Baselines. В первом окне мастера старую базовую линию vob1_initial надо удалить (кнопка “Remove”), и добавить новую (соответственно “Add”). После нажатия “Add” надо выбрать созданную базовую линию – BL1.

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

С

Рис.6



оздать поток разработчика, а вместе с ним корректно настроенный вид, удобнее всего, запустив соответствующего мастера из утилиты ClearCase Home Base -> Projects -> Join Project. Сначала надо выбрать проект, к которому Вы хотите присоединиться (Рис.6). В следующем окне выведены два названия потоков – верхний, разработчика, - который Вы создаёте, и нижний – поток слияний – тот поток, в который будут сдаваться действия из создаваемого потока. Соответственно, создаваемый – project1_dev_str, и поток слияний – project1_integration (Рис.7). После завершения ещё нескольких стандартных для ClearCase операций (имя создаваемого вида, выбор буквы для диска MVFS, разрешение-запрещение создания общедоступных Derived Object’ов), будет создан поток и вид разработчика (в примере соответственно project1_dev_str и project1_dev_view). Существование этих объектов можно обнаружить следующим образом: поток разработчика появится в древовидной структуре потоков в Project Explorer, а новый диск MVFS (project1_dev_view) отобразится, например, в ClearCase Explorer.

Рис. 7



С

Рис.8 Контекстное меню потока разработчика в ClearCase Explorer.


ледующий этап – это взятие файла на редактирование в виде разработчика (под новым действием), правка его, возвращение в базу данных, и, сдача этого действия в поток слияний. Все шаги стандартны: из любого браузера с диска MVFS, который представляет собой вид разработчика, выводим файл на редактирование (check out) подобно тому, как мы это делали в виде интегратора. Необходимо создать новое действие, с которым будут ассоциироваться изменения файла в виде разработчика. Теперь можно править файл. После того как сделаны все необходимые изменения, версия элемента протестирована, и признана разработчиком, как “имеющей право на жизнь”, он возвращает файл в компонентный VOB (check in). Теперь перед разработчиком стоит задача отдать интегратору результат своей работы. В UCM эта операция называется сдачей действия (Deliver Activities). В последних версиях ClearCase (начиная с v2002) имеется возможность сдавать действия не только в поток по умолчанию (тот, который назначался при создании потока разработчика), но и в любой другой поток. Соответственно опции в контекстном меню потока разработчика - “Deliver from Stream to Default” и “Deliver from Stream to Alternative Target” (при работе с файлом, например, из утилиты ClearCase Explorer). Но в рамках рассматриваемого примера имеет смысл сдавать действие только в поток слияний (т.к. другого просто нет) Рис.8. Мастер сообщит какое действие он обнаружил для сдачи в другой поток. После этого он сам сливает файлы, если различия незначительны. Если же отличия от базовой линии в каких-либо файлах есть в обоих потоках, то запустится специальная утилита и поможет Вам корректно слить эти файлы (DiffMerge).


Теперь интегратор в своём потоке (слияний) может создать новую базовую линию с учётом изменений, сданных разработчиком. Делается это из Project Explorer выбором в контекстном меню потока слияний опции “Make Baseline”. После этого процесс повторяется циклически, пока ПО не достигает желаемого уровня функциональности и стабильности.


Стоит отметить, что все выше перечисленные действия можно проделать при помощи командной строки Rational ClearCase (cleartool). Конечно, работа с командной строкой требует больше времени, но простота графического интерфейса не всегда бывает достаточной. Объясняется это тем, что полная функциональность Rational ClearCase доступна лишь при работе с командами утилиты cleartool. Приведём список команд, которые необходимы для работы с ClearCase в UCM: mkvob, mkhlink, mkview, mkcomp, mkproject, mkstream, lsbl, mkactivity, setactivity, checkout, mkdir, checkin, mkelem, mkbl, chstream, deliver, rebase. Комментарии ко всем приведённым командам можно найти в ССЫЛКА НА ГЛАВУ С КОМАНДАМИ.


Метаданные VOB


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

Метаданные являются средством расширения и дополнения стандартных функций 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».

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

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

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

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


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

Element Type


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

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

Врезка12

Отметим основные предназначения модуля 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


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

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

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

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

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

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

На рисунке 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


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

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

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

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

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

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

Врезка15

Обратите внимание на рисунок 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


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

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

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

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

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

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


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

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

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

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

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


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

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

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


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


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


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


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


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


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


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


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

Hyperlink type


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

Необходимость в наличии гиперссылок связана с тем, что в проектах очень часто бывает необходимым проставить связи между объектами, или между различными версиями различных объектов. Например, таким образом можно соединять зависимые объекты или данные. 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


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

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

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

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

Пользовательские триггеры в 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_USER}=~"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.

Врезка17


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


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

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

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

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

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

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

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

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


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


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


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


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


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


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


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


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


Общие принципы работы с командной строкой в ClearCase


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

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

Большая часть функциональности ClearCase находится именно в командах командной строки.

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


Cleartool.exe. Для всех команд ClearCase

Multitool.exe. Для управления модулем синхронизации регионально удаленных команд – MultiSite


Интерпретаторы работают в консольном режиме. После инсталляции ClearCase все интерпретаторы будут находиться в директории ” bin”. Для простоты использования можно их переименовать, сократив имя до 2-3 букв, поскольку при интенсивном обращении к командной строке набирать полное наименование не всегда представляется возможным и целесообразным.

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

В пакетном режиме указывается имя интерпретатора и через пробел команду и ее параметры, например, cleartool lsvob –l”.

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

В качестве языков скриптов ClearCase «понимает» обычные Batch-файлы, а также Perl-файлы (сам язык Perl входит в поставку ClearCase).

В пакетном режиме можно ставить переадресацию вывода «>» или «>>», например, для создания текстового файла с отчетом по исполнению команды. Например, «cleartool lsvob –l >> report.txt». Давайте запомним эту возможность, поскольку к ней не раз придется прибегать.

Любая команда формируется по определенным законам, справедливым для большинства команд.

Принцип построения таков:


[команда] [данные] [-ключи]

или

[команда] [-ключи] [данные]


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

Рассмотрим основные:


-graphical. Для выдачи результатов вызывает графическое окно. Интересная возможность в случае со сравнением данных. В чистом графическом сравнении, имеется возможность по сравнению только 2 версий файла и получению их разницы в окне «compare». В случае командной строки можно сравнивать одновременно несколько версий – 2,3… и так далее, а выдачу результатов перенаправить в графическое окно, а не в консоль;


-long. Подробная информация. По умолчанию ClearCase всю выдачу производит в коротком виде (brief). Команда используется для получения более детального отчета;


-full. Данный переключатель, в некоторых командах, может замещать предыдущий;


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


-comment “комментарий”. Для большинства операций по манипуляции данными предусмотрены комментарии. В случае, когда пользователь набирает команду, требующую комментирования, но не описывает его данным ключом, система дополнительно запросит комментарий в специальном окне. Для формирования пакетных файлов, обычно, не предусматривается взаимодействие с пользователем, соответственно команде, в качестве аргументов передается данный ключ, с комментарием, находящимся в кавычках;


-nc. Ключ ставит операции пустой комментарий;


Дополнительно отметим, что имена команд и имена переключателей можно вводить в сокращенном виде, например, вместо «-comment» использовать более короткий «».

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

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

Например:


Man lsvob

Man –g lsvob


Язык запросов

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

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

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

Язык запросов состоит из:


-функций запросов. Функция состоит из имени и из передаваемого значения. Результат работы функции – значения ИСТИНА или ЛОЖЬ (true, false);


-атрибутов запросов. Наименования атрибутов берутся из метаданных VOB, например, имя метки, наименование элемента;


-операторов сравнения и логики. Логических операторов, осуществляющих связи между функциями запросов.


Любой запрос обрамляется фигурными скобками {}. Функции могут группироваться в модули при помощи круглых скобок.


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

== Равно. Используется нотация языков С\С++;

< Меньше;

<= Меньше или равно;

> Больше;

>= Больше или равно;

!= Не равно.


Логические операции:


&& Логическое «И»;

|| Логическое «ИЛИ»;

! Логическое «НЕ».


Функции языка запросов:

Attype(). Возвращает значение «ИСТИНА», если находит атрибут с заданным типом

{Attype(Errors)}. Найти элементы, с установленным атрибутом «Errors»

Brtype(). По типу ответвления.

{brtype(Asteroid)}. Найти элементы, у которых есть ответвление «Asteroid»

{brtype(Asteroid) && Attype(Errors)} Найти элементы имеющих атрибут «Errors» и бренч «Asteroid»;


created_by(). По имени владельца. ClearCase для при проведении любых операций запоминает имя пользователя. В отличие от остальных продуктов Rational (ClearQuest, RequisitePro, Robot) СС пользуется не собственной библиотекой имен, а системными именами.

{created_by(Ivanov)}. Найти элементы, пользователем которых является данный пользователь;

{!created_by(Ivanov)}. Найти элементы, которые создавали все пользователи кроме Иванова.


created_since(). Найти по дате создания. Используется для поиска элементов созданных пользователем или группой пользователей;

{created_since(yesterday.13:00)}. Найти элементы созданные вчера, в 13:00


eltype(). По типу элемента. Позволяет искать версии элементов по их типу. Тип элемента, как известно, задается при его создании.

{eltype(zip_archive)}. Найти элементы zip_archive

{eltype(directory)}. Найти директории


hltype(). По типу гиперссылки.

Например:

{hltype(tested)}. Найти элементы с гиперссылками tested


lbtype(). По типу метки. Позволяет искать версии элементов по меткам, например, найти все версии файлов релиза 1 (Rel1);

Например:

{lbtype(Rel1.0)}. Найти версии элементов с заданной меткой


trtype(). По типу триггера. Позволяет узнать какому элементу присвоен данный триггер

Например:

{trtype(my_trigger)}. Найти элементы, на которых есть указанный триггер



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

Отметим основные, прямые предназначения, для которых создавался язык запросов:


-работа совместно с Конфигурационными Спецификациями (config spec). Поскольку каждый вид в СС производит выборку по определенным правилам, то их модификация может существенно улучшить его характеристики. Например, заменив стандартную конфигурационную спецификацию element * main/LATEST на

element * main/{created_by(Ivanov)}, мы получим в динамическом виде список только тех элементов, которые создавал указанный пользователь. Далее усложнять спецификации для получения произвольной выборки. Например, очень эффективно построить правило выборки элементов по дате, чтобы можно было просмотреть вновь созданные или измененные элементы. Также необходимо создать спецификации для тестировщиков, куда будут выводиться только те версии элементов, на которых находится атрибут представления к тестированию. Также можно создать вид, насыщаемый уже протестированными версиями. Это основные моменты. Более подробно смотрите в главе виды и в документации на СС;

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

find . -ver "warnings>0 && warnings <5 " -all -print






Язык аннотирования и форматного вывода

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

ClearCase имеет богатые средства по формированию отчетности. Отличительной способностью продукта является не просто формирование отчета, а формирование унифицированного отчета установленного образца. Мы уже рассматривали ряд команд, которые позволяют получать описательную информацию о состоянии тех или иных элементов репозитория. В большинстве случаев, выразительности таких команд как describe, annotate, lshistory вполне хватает.

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

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

Команды формата заключаются в парные кавычки.


Наименование атрибута начинается со знака процент - %


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


%c. Вывод комментария. Распечатывается комментарий, присвоенный версии элемента. Как правило, отсутствие комментария на версию можно считать исключением, так как по RUP полагается описывать каждое действие в момент его исполнения;


%d. Вывод даты. Описывается дата и время проведения операции над версией элемента.


%e. Описание среды. Позволяет определить тип операции, назначенной версии элемента (создание версии, ответвления, гиперссылки, и т.д.). Применяется для получения четкого представления о операции;

%f. Отчет о версии элемента, находящегося в состоянии check-out. Позволяет описать состояние версии элемента в данном состоянии, например, описать статус (резервный\не резервный) и вид, в котором версия элемента находится в разработке;


%h. Наименование хоста. Поле позволяет определить имя компьютера, на котором была проведена операция для данной версии элемента;


%l. Наименование метки. Позволяет просмотреть имена меток, назначенных для данной версии элемента;


%n. Имя объекта. Просмотр различных представлений имен для версии элемента (ключ имеет ряд модификаторов, определяющих различные представления имени (полно, сокращенное, и т.д.);


%o. Тип применяемой операции. Описывает предшествующую операцию;


Специальное действие (спец. Символ) начинается со знака слеш - /


/n. Перейти на новую строку;

/t. Вставить табулятор.


Рассмотрим пример команды, использующей аннотированный форматный вывод:


lstype -fmt "Label type: %n\tMaster: %[master]p\n" -kind lbtype


describe -fmt "Имя: %n\n

Имя элемента: %En\n

Версии: %Ln\n

Сокращенное имя: %Sn\n

Номер предыдущей версии: %PSn\n

Идентификатор версии: %Vn\n

Идентификатор предыдущей версии: %PVn\n

Расширенное путь имени: %Xn\n

Атрибуты: %a\n

Значения атрибутов: %Sa\n

Комментарий: %c

Дата и время: \tdefault: %d\n

Время в днях: %Ad\n

Время в месяцах: %MAd\n

Имя хоста: %h\n

Метки: %Cl\n

Предок объектов: %m\n

Предок операции: %o\n

Событие: %e\n

Пользователь: %u\n

Полное имя пользователя: %Fu\n

Имя группы: %Gu\n

Длинное имя: %Lu\n\n" main.c


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

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

Основные команды командного интерпретатора cleartool


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


annotate

Аннотирует (описывает) изменения, проведенные с элементом. Для работы использует создание временного текстового файла с аннотацией, помещаемого рядом с аннотируемым (присваивается расширение ann. Созданный файл не ставится под управление и представляется private объектом для созданного вида). Поддерживает форматный вывод с использованием выражений. Особенно эффективна команда при составлении отчета по содержимому элемента, по расписанию.


annotate -fmt "%a %c" -rmnheader util.c
Выводит информацию о версиях файла. Для вывода используется форматный способ.

annotate -long msg.c

Описывается файл msg.c стандартным образом в расширенном варианте

annotate -short msg.c

Описывается файл msg.c стандартным образом в сокращенном варианте


catcs

Получить конфигурационную спецификацию для текущего или указанного вида


Catcs

Получить CS для текущего вида

Catcs –tag Development

Получить CS для вида с именем Development


cd

Сменить директорию. Обычная системная команда, дополнительно реализованная в интерпретаторе СС

Cd ..

Перейти на уровень выше

Cd m:\myvob

Перейти в указанный VOB (в корневую директорию репозитория)


checkin

Перевести элемент в данное состояние (зарегистрировать в базе)


Cinc .

Зарегистрировать текущую директорию. Операцию проводить без присвоения комментариев


Cicfirst outmain.cpp

Зарегистрировать файл с присвоением комментария

Ci main.cpp

Зарегистрировать файл. Во время регистрации СС дополнительно запросит комментарий для данной операции


checkout

Вывести файл в данное состояние для внесения в него изменений


Conc .

Вывести в режим редактирования текущую директорию (без комментария)

Coc “Правка” main.cpp

Вывод файла с предустановленным комментарием


checkvob

Проверить структуру репозитория на наличие ошибок. Позволяет проверять и исправлять ошибки связанные с хранилищем данных, с глобальными типами и с гиперссылками. Используется администраторами для восстановления функционирования репозитория. Проверяется целостность как всего репозитория, так и его отдельных элементов. По результатам работы, в VOB, выводится директория с описанием проведенных действий. Элементы директории являются Privat-данными, и отображаются только во view, с которого был инициирован процесс проверки.


Checkvob main.cpp

Проверить файл на наличие ошибок

Checkvob –pool –source \\compa\stg\vobs\test.vbs

Проверить все элементы указанной базы на наличие ошибок


chevent

Изменяет комментарий для указанный версии.

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


Chevent main.cpp@@/main/2

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

Cheventc “Короткая правка” stdlib.h@@/main/1

Изменить комментарий, сопровождающий версию 1, на “Короткая правка”


сhstream

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

chstream -c "demo" -recommended new_bl int_str@\pvob1

Изменить рекомендованную базовую линию потока “int_str@\pvob1”.


chtype

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


chtype file hello.c

Приводит тип элемента hello.c к file

chtype -c "Релиз больше не используется" closed util.c@@\main\Rel2.0BugFix

Изменить ветвь Rel2.0BugFix на closed, с сопровождающим комментарием


cptype

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


Cptype brtype:Rel1.0BugFix Rel2B.0ugFix

Создать новый тип ответвления Rel2B.0ugFix , свойства которого будут идентичны имеющемуся Rel1.0BugFix,

Cptype lbtype:Rel1.0@\old_vob Rel1.0@\new_vob

Скопировать тип метки из одного репозитория в другой


deliver

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

С просмотром изменений перед сдачей;

С указанием действий, потока или базовой линии, которые необходимо сдать;

С разрешением конфликтов слияния работ;

С тестированием и компилированием сданных работ в потоке слияний;

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


deliver -stream dev_str@\pvob1 -to int_view -activities dev_act –force

Сдача действия. Довольно простая ситуация - типы файлов известны ClearCase, данный процесс сдачи не пересекается с другим, подобным. Ключи в данном случае:

stream” – указываем поток, из которого происходит сдача действия (dev_str@\pvob1);

to” – вид, прикреплённый к потоку слияний (“int_view”);

activities” – перечень сдаваемых действий (“dev_act”);

force” – ClearCase исключает участие пользователя в сдаче действия и процесс слияния (merge) происходит автоматически.


describe

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

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


Desc main.cpp

Дать описание файлу main.cpp, в соответствии с установками по умолчанию

Desc lbtype:Rel1.0

Дать описание свойствам метки Rel1.0

describe -fmt "ИМЯ: %Xn\nТип объекта: %m\n" main.cpp

Дать описание свойствам файла, с использованием форматного вывода (см. форматный вывод)

Describelong vob:.

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


diff

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

Используется в скриптах, основное применение – сравнение сразу нескольких версий одного элемента, или нескольких элементов.


Diff main.cpp main.cpp@@/main/1

Сравнить две версии одного элемента в текстовом режиме

Diff –g main.cpp main.cpp@@/main/1 main.cpp@@/main/3

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

Diff dir dir@@/main/2

Сравнит две версии директории. При этом можно наблюдать только состав самих директорий (наличие\отсутствие файлов)


diffcr

Сравнивает две и более конфигурационных записей (результатов компиляции), получаемых в результате работы omake и clearmake

Применяют в случае наличия сложной истории перекомпиляций проекта


diffcr -flat release.exe release.exe@@11-aug.19:30.2002

Сравнить текущую запись с записью от указанной даты


edcs

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

Используется для локальной правки CS. Команда не воздействует на оригинальные профили и спецификации сервера и не может помешать остальным участникам проекта


Edcs

Вызов конфигурационной спецификации для ее правки (вызывается редактор по умолчанию – notepad). Для текущего вида

Edcstag Development

Вызов редактирования CS для указанного вида Development, при этом находится можно в любом View


find

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

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


find . -element "eltype(directory)" -all –print

Найти и распечатать на экране все элементы, тип которых ДИРЕКТОРИЯ. Поиск осуществляется от текущей директории.

find . -ver "version(/main/0) && created_by(admin)" -all –print

Найти все элементы, у которых есть НУЛЕВАЯ версия, созданная пользователем admin. Все полученные данные распечатать на экране. Поиск осуществляется от текущей директории.

find . -name "*.txt" -exec 'cleartool describe %CLEARCASE_PN%'

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


findmerge

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


findmerge . -fversion /main/Rel1BugFix/LATEST -all –print

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

findmerge . -fversion /main/Rel1BugFix/LATEST -allmerge

Тоже, что и предыдущий пример. Разница состоит в то, что после нахождения версий, требующих слияния, СС сам начнет объединять их.


fix_prot

Системная команда. Позволяет исправлять права доступа к файлам и директориям проекта на физическом уровне.

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


fix_prot.exe -force -root -chown student -chgrp None c:\stg\vobs\TestCC.vbs

Изменяет права на владения репозиторием.


get

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


ln

Выполняет связку объектов. В СС, как и в Unix, существует два типа связей: мягкие и жесткие. Команда применяется в тех случаях когда необходимо создать экземпляр одного элемента в нескольких директориях одного проекта, или для создания ссылки на объект из другого проекта, репозитория (символическая).

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


lnslink ..\RTS .

Создать символическую связь с директорией RTS. Ссылка монтируется в текущую директорию.

ln -slink msg.c messages.c

Создать символическую связь файла messages.c, поместить ее в текущую директорию и дать имя новому элементу msg.c

ln *.cpp subd

Создать ссылки на все файлы CPP и поместить их п в поддиректорию subd


lock

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


lock vob:.

Заблокировать для всех текущий репозиторий

lock *.cpp

Заблокировать все файлы CPP, находящиеся в текущей директории

lock brtype:Rel2.0BugFix

Заблокировать бренч Rel2.0BugFix для всех элементов, его содержащих


ls

Выводит на экран список элементов текущей или указанной директории

lslong

Вывести полную информацию о элементах из текущей директории

lsnxn

Вывести сокращенную информацию о элементах из текущей директории


lsco

Выводит на экран список элементов находящихся на редактировании (в состоянии check-out)

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

lscheckout -short

Вывести список файлов, находящихся в данном состоянии. Поиск ведется для текущей директории, вывод осуществляется в сокращенном формате

lscheckout -recurseuser admin

Рекурсивно вывести список файлов, находящихся в состоянии СО. Вывод фильтруется для пользователя admin


lsdo

Выводит на экран список элементов типа derived-objects


Lsdo .

Простой вывод объектов компиляции для текущего репозитория и текущего вида

Lsdolong .

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


lshis

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


Lshistory main.cpp

Вывод истории изменений для файла main.cpp. Вывод осуществляется для всех ответвлений

lshistory -long lbtype:REL1 .

Вывод истории изменений элементов текущей директории, у которых есть метка REL1

lshistory -user admin -a -minor -since 20-mar-99.15:00

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


lslock

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


lslockall

Прсомотреть в текущем репозитории список заблокированных элементов


lspriv

Выводит на экран список личных элементов. Причем, в СС личные файлы выделяются не на конкретного пользователя, а на конкретный вид. Тем самым, если на локальной машине пользователя 3 разных вида, то для каждого из них выделяется свое, изолированное от остальных, личное пространство.


lsprivate -invob M:\Development\Vob\src

Выводит список личных объектов для директории src, репозитория Vob. Поиск ведется по глобальному доступу, через букву M

lsprivate -long

Выводит список личных объектов для всех репозиториев


lsreg

Выводит список доступных регионов


lsreplica

Выводит список реплик синхронизации для текущего или указанного репозитория.


Lsreplica

Список репликаций для текущего репозитория

Lsreplicainvob \MyVob

Список репликаций для указанного репозитория


lstype

Просмотреть список метаданных по типам


Lstypekind lbtype

Вывести список типов меток с характеристиками (для текущего репозитория)

Lstypekind brtype

Вывести список типов ответвлений с характеристиками (для текущего репозитория)

lstype -fmt "%n %c \n" -kind lbtype

Вывести список типов ответвлений с использованием форматного вывода


lsview

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


lsview -long

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

lsview -host asteroid

Вывести стандартный список видов для компьютера asteroid

lsview -properties -full

Вывести расширенный список видов со свойствами для компьютера asteroid


lsvob

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


lsvob -long \vob12

Вывести полную информацию о репозитории vob12

lsvob -graphicalregion windows

Отобразить графически список репозиториев региона windows

lsvobhost asteroid

Отобразить список репозиториев для указанного компьютера


lsvtree

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


lsvtree util.c

Вывести дерево версий для файла util.c (в консоль)

lsvtreeg util.c

Вывести дерево версий для файла util.c (в виде окна, в графическом исполнении)

lsvtreeall

Вывести дерево версий для каждого элемента

lsvtree -branch \main\Rel2.0BugFix -all util.c

Вывести фрагмент истории, только для версий бренча Rel2.0BugFix


merge

Слияние одной или нескольких версий в одну. Операция может выполняться как в графическом, так и в текстовом режимах. Ценность команды – в способности слияния более двух версий одновременно. Из особенностей можно отметить, что в результате слияния нескольких версий не отображается графическая связь между ними (отображается только для двух версий)

merge -to util.c -graphical -version \main\Rel2.0BugFix\LATEST

Провести графическое слияние двух версий файла util.c. Источником будет версия \main\Rel2.0BugFix\LATEST, а приемником версий, выведенная предварительно в состояние check-out


mkactivity

Создать действие. Действие отслеживает все работы разработчика по завершению поставленной задачи. Каждый поток может иметь лишь одно текущее действие, в которое записываются все сделанные изменения. Если действие не должно использоваться немедленно, необходимо использовать ключ “nset”:


mkactivity -c "demo" -in int_str@\pvob1 -nset act_int@\pvob1

Создать действие “act_int@\pvob1” в потоке “int_str@\pvob1”, не устанавливая его в текущем виде (ключ “nset”)


mkattype

Создать тип атрибута для последующего назначения элементам


mkattype -nc Additional

Создать атрибут по умолчанию

mkattype -nc -vpbranch -vtype integer -gt 0 -le 10 Errors

Создать атрибут Errors, тип значений которого, Ineger. Задать пределы для ввода: от 0 до 10

mkattype -nc -enum ‘"НЕТ","ДА","в процессе"’ Tested

Создать атрибут Tested, с тремя предопределенными состояниями


mkattr

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


mkattr Tested \"ДА\" hello.h

Назначить созданный атрибут Tested на файл hello.h, с присвоением значения \"ДА\"


mkbl

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


mkbl -c "demo" -view int_view -activities act_int@\pvob1 -full new_bl

Создать новую базовую линию в виде “int_view” (ключ “view”), составив её из всех элементов компонента (ключ “full”), изменённых действием “act_int@\pvob1” (ключ “activities”).


mkbrtype

Создать тип ответвления для последующего назначения элементам


mkbrtype -c "Отладочный релиз для версии 2.0" Rel2.0BugFix

Создать отладочный релиз Rel2.0BugFix с присвоением комментария (один релиз на элемент)

mkbrtypepbranch -c "Отладочный релиз для версии 2.1" Rel2.1BugFix

Создать отладочный релиз Rel2.йBugFix с присвоением комментария (одно ответвление для одного бренча)


mkbranch

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

Достаточно часто данная команда применяется администраторами при устранении дефектов ведения проекта совместно с командой find


mkbranch -nc bugfix util.h

Создать ответвление bugfix для последней версии util.h, и вывести его в состояние chek-out

mkbranch -version \main\1 -nco -nc Rel3.0BugFix util.c

Создать ответвление Rel3.0BugFix от версии 1 файла util.c, без комментирования операции. Результирующее состояние версии check-in


mkcomp

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


mkcomp -cdemo” -root M:\temp_view\vob1 vob1@\pvob1

Создаётся компонента “vob1” в репозитории “\pvob1”, в которую включен репозиторий “M:\temp_view\vob1”.


mkdir

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


Mkdirnc Source

Создать директорию Source, без применения комментария

Продемонстрируем применение ключа “nco”:

mkdir -nco -c "demo" M:\int_view\vob1\files

Создать директорию без постановки её в состояние редактирования (checkout).


mkeltype

Создать тип элемента. Используется для тонкой настройки проектных данных по типам файлов, для организации. Новый элемент может создаваться на основе супертипа. Все возможные файловые структуры описываются в Magic-файлах.


mkeltype -supertype file -nc zip_archive

Создать новый тип элемента zip_archive, свойства которого базируются на основе предопределенного типа file

mkeltype -supertype file -mergetype never -nc grph_file

Создать новый тип элемента grph_file, свойства которого базируются на основе предопределенного типа file и задать специальные свойства конструирования версии по переменной never


mkelem

Создать элемент. Используется для постановки под контроль данных. Для постановки под управления данные должны находится в виде.

mkelem -eltype directory dira

Создать элемент директория с именем dira

mkelem -nc -ci main.cpp

Создать элемент main.cpp (по умолчанию – текстовый файл), без комментирования процесса. Результирующее состояние файла после операции – check-in

mkelem -nc main.cpp

Создать элемент main.cpp (по умолчанию – текстовый файл), без комментирования процесса. Результирующее состояние файла после операции – check-out

mkelem -nc -eltype zip_archive arch.zip

Создать элемент arch.zip, с присвоением ему типа zip_archive


mkhltype

Создать тип гиперссылки для последующего назначения элементам

mkhltype -nc tested_by

Создать тип гиперссылки tested_by

mkhltype -c "исходные тексты для дизайна документов" design_spec@\docs

Создать тип гиперссылки design_spec и связать ее с директорией docs


mkhlink

Назначить тип гиперссылки на указанные объекты. Гиперссылки используются в основном для формирования логических связей, как внутри одного репозитория, так и с «внешним» миром, например, для связи с дефектами в ClearQuest, используется именно механизм гиперссылок. Также удобно применять данный метод для ссылки на внешние документы (возможно, на основании которых, разрабатывалась версия в СС). Не менее активно гиперссылки используются при работе с СС в рамках UCM для связи компонентного и административного (проектного) репозиториев.


mkhlink design_spec main.cpp@@\REL2 \users_hw\doc\util.doc@@\REL2

Связать две версии разных файлов ссылкой design_spec

mkhlink -ttext "Регрессия" tested_by main.cpp

Назначить текстовую метку tested_by на файл main.cpp

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

mkhlink AdminVOB vob:\vob1 vob:\pvob1

Репозиторий “\pvob1” назначается проектным для компонентного “\vob1”.


mklbtype

Создать тип метки


mklbtype -c "Релиз 2.0" Rel2.0

Создать тип метки Rel2.0 (с комментарием, одну на элемент)

mklbtype -nc -pbranch Rel3.0

Создать тип метки Rel3.0 (без комментария, одну на ответвление)


mklabel

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


mklabel -recurse Rel6.0 .

Назначить тип метки Rel6.0 для всех элементов, расположенных в текущей директории и во всех дочерних поддиректориях

mklabel -recurse -version /main/1 Rel1.0 *.cpp

Назначить метку Rel1.0 всем файлам, с расширением cpp, расположенным в текущем репозитории


mkproject

Создать проект. Активно используется при работе с СС в рамках UCM. Проект создаётся в какой-либо директории (можно в корневой директории репозитория), и должен содержать компоненты (одну или несколько):

mkproject -c "demo" -modcomp vob1@\pvob1 -in RootFolder@\pvob1 demo_project@\pvob1

Создаётся проект “demo_project@\pvob1” в корневой директории репозитория “\pvob1 ”, содержащий изменяемую (ключ “modcomp”) компоненту ” vob1@\pvob1”.


mkregion

Создать новый регион. Регионы используются для структуризации репозиториев (для каждого региона можно создавать одинаковые имена репозиториев). Но чаще регионы применяются при одновременной работе на распределенных платформах (Unix\Windows).


Mkregiontag 1stFloor

Создать регион с указанным именем


mstream

Создать поток. Используется при работе с СС в рамках UCM-проекта. Поток состоит из имени, набора базовых линий, записи о наборе действий, связанных с потоком. Различают два вида потоков – поток слияний и поток разработчика. Интеграционный поток создаётся с использованием ключа “int”. Для потока слияний указывается проект, для потока разработчика указывается родительский поток (обычно – поток слияний):


mkstream -int -in demo_project@\pvob1 -baseline vob1_INITIAL@\pvob1 int_str@\pvob1

Создаётся поток слияний “int_str@\pvob1” в проекте “demo_project@\pvob1” с базовой линией “vob1_INITIAL@\pvob1”.


mktag

Создать логическое имя вида или воба в регионе. Позволяет присваивать физически имеющимся видам и репозиториям новые логические имена. В основном используется в распределенных системах для связи с UNIX репозиториями, но также применяется при переносе VOB и VIEW с сервера на сервер (совместно с командой Register).


mktag -view –tag Rel1.0 -region Windows \\comp1\stg\views\Rel1.0.vws

Создать тег (логическое имя) для вида Rel1.0 в регионе Windows, основываясь на физической базе Rel1.0.vws


mktrtype

Создать тип триггера. СС обладает событийно-ориентированнм интерфейсом. Триггер поможет дополнить функциональность (более подробно, см. главу про триггеры)


Mktrtype –element –all postop checkout –exec ‘net send comp1 %CLEARCASE_PN%-is CO’ co_send

Создать тип триггера co_send для всех элементов, выводящихся в состояние checkout. Триггер срабатывает после работы стандартного обработчика событий СС. Триггер инициирует, системной командой net send, отправку сообщения на консоль с именем comp1, в качестве дополнительных параметров, на консоль отправляется адре элемента, выводимого в CO (через переменную среды)

Mktrtype –element –all –preop checkout –eltype zip_file –nusers admin,manager –exec ‘ccperl –e \”exit(-1);\”’ exept_trigg

Создать тип триггера exept_trigg для всех элементов, выводящихся в состояние checkout.

Триггер срабатывает для всех пользователей, кроме перечисленных. Передача управления триггеру производится до стандартного обработчика. В случае совпадения несовпадения имени пользователя выполнится условие exit (-1) – команда на прерывание действия, и СС не выведет элемент в данное состояние

Mktrtype –element –preop checkout –nusers admin,manager –exec ‘ccperl –e \”exit(-1);\”’ exept_trigg_for_file

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

mktrtype -nc -element -all -preop rmver -brtype main –nusers admin,manager –exec ‘ccperl –e \”exit(-1);\”’ exept_trigg_for_branch

Создать тип триггер, запрещающий удалять версии с основного дерева версий. Исключение составляют пользователи admin и manager.


mktrigger

Создать триггер для элемента (более подробно, см. главу про триггеры)


mktrigger exept_trigg_for_file main.cpp

Назначить созданный тип триггера exept_trigg_for_file на файл main.cpp


mkview

Создать вид. В зависимости от параметров создает либо статический, либо динамический вид. При создании динамического вида данной командой создается лишь само представление, но не создается ассоциация с буквой диска. Следует отметить ключ “stream” данной команды. Он применяется при работе с СС в рамках UCM для прикрепления вида к какому-либо потоку.


mkview -tag Development \\alex-golder\stg\views\Development.vws

Создать вид с именем Development, сохранив его по указанному адресу

net use * \\view\Development

Создать сетевой диск Development, с присвоением произвольной буквы

mkview -tag int_view -region Windows -stream int_str@\pvob1 \\sash\stg\views\int_view.vws

Создать вид и прикрепить его к потоку “int_str@\pvob1”.


mkvob

Создание репозитория. Основная команда СС, без особых отличительных способностей. Исключение составляет платформа UNIX, так как там формат команды намного сложнее Windows-аналога


mkvob -nc -tag \Allo \\comp1\stg\vobs\ssa.vbs

Создать репозиторий с именем \Allo, расположив его по указанному пути.

Обратим внимание на ключ команды “-ucmproject”. Он необходим при работе с СС в рамках UCM. При использовании данного ключа создаётся проектный репозиторий:

mkvob -tag \pvob1 -ucmproject -cdemo” -region Windows \\sash\stg\vobs\pvob1.vbs


mount

Смонтировать один или несколько репозиториев


Mount \Allo

Смонтировать репозиторий \Allo


Mv


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

Mv main.cpp src1

Перенести файл main.cpp из текущей директории в src1


protect

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

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


protect -chmod +r main.cpp

Разрешить чтение данных из файла main.cpp

protect -recurse -chgrp user src

Поменять группу владельца элементов с user на src

protect -chown tester brtype:Rel1.0BugFix

Поменять владельца ответвления


pwd

Получить имя текущего диска


pwv

Получить имя текущего вида

rebase

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


rebase -view dev_view -baseline bl_after_test

Вид наполняется версиями файлов базовой линии, указанной за ключом “-baseline” (“bl_after_test”).


reformatview

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


reformatvob

Преобразовать VOB в промежуточный формат для переноса на иную платформу. Применяется при переносе базы с одной платформы на другую (с Unix на Windows и обратно). Применяется в пакете с командами управления правами и регистрацией.


register

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


Register –vob \\comp1\stg\vobs\ssa.vbs

Зарегистрировать, сделав доступным, репозиторий из указанной директории


relocate

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


Relocate src ../vob2

Перенести элементы из директории src (текущего репозитория) в репозиторий vob2


rename

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


Rename main.cpp supermain.cpp


reserve

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


reserve main.cpp


rgy_passwd

Устанавливает пароль на работу с данными на регистрационном сервере.


rmattr

Удалить атрибут


Rmattr Tested main.cpp

Удалить атрибут Tested с элемента main.cpp

rmattr -version '\main\{Tested=="Нет"}' Tested main.cpp

Удалить значение НЕТ атрибута Tested с элемента main.cpp

rmattr -version \main\3 Tested main.cpp

Удалить атрибут Tested с 3 версии файла main.cpp


rmbranch

Удалить ответвление


mbranch main.cpp@@/main/Rel1.0BugFix

Удалить ответвление Rel1.0BugFix с дерева версий файла main.cpp


rmelem

Удаление элемента с деревом версий из репозитория без возможности восстановления. Очень опасная команда, безвозвратно уничтожающая элементы репозитория. Исключения составляют случаи, удаления директорий, когда все вложенные в директорию элементы перемещаются в папку lost+founds.


Rmelem main.cpp

Удалить файл main.cpp

Rmelem dir1

Удалить директорию dir1


rmhlink

Удалить внешнюю связь


rmlabel

Удалить метку с элемента


rmlabel -version \main\Rel2.0 Rel2.0 main.cpp

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

rmlabel Rel2.0 main.cpp

Удалить метку с элемента (подразумевается, что метка одна на элемент)


rmmerge

Удалить ранее проведенное слияние объектов. При удалении версии элементов и их содержимое остаются неизменными. Особенность команды заключается в том, что удаляется только визуальная связь на дереве версий. При этом, версия созданная в результате слияния остаетс нетронутой. Если необходимо удалить е Ии, то применяется команда rmver.


rmmerge main.cpp @@/main/Rel2.0BugFix/LATEST main.cpp

Удалить слияние текущей версии элемента main.cpp с последней версией отладочного релиза Rel2.0BugFix


rmname

Удалить имя элемента. Данная команда может быть использована для удаления элемента из текущей версии директории (при вводе команды директория должна находиться в состоянии check-out). Рекомендуется к использованию вместо rmelem, так как не удаляет данные физически из репозитория.


Rmname main.cpp

Удалить элемент из состава текущей директории

rmname -nco .@@\main\2\main.cpp

Удалить элемент main.cpp из второй версии текущей директорий, без вывода ее в состояние check-out


rmregion

Удалить регион


Rmregion –tag Windows


rmtag

Удалить логическое имя репоизитория или вида. Команда удаляет только логическое имя, оставляя нетронутыми физические базы VOB и VIEW (stg\vobs и stg\views). Применяется в тех случаях, когда необходимо отделить физическое хранилище данных от его представления в СС.


rmtag -view Rel2.0BugFix

Удалить имя вида Rel2.0BugFix

Rmtagvob \Sem

Удалить имя репозитория \Sem


rmtrigger

Удалить поставленный триггер


Rmtrigger my_trig

Удалить триггер my_trig


rmtype

Удалить тип метаданных. Отметим, что удаления типа метаданных приводит к их уничтожению на версиях элементов в репозитории.


rmtype brtype:Rel1.0BugFix

Удалить тип ответвления

rmtype -rmall lbtype:Rel1.0

Удалить тип метки


rmver

Удаление конкретной версии или диапазона версий с дерева версий элемента. Используется в крайних случаях, как мера по приведению версионного дерева в порядок. Команда rmver по умолчанию удаляет только одну версию или диапазон независимых версий, то есть таких версий, от которых нет ответвлений и на которых нет меток.


rmver main.cpp

Удалить текущую версию элемента для данного вида

rmver –version /main/3 main.cpp

Удалить версию 3 с основного ответвления

rmver –xla –xbr –version /main/3 main.cpp

Удалить 3 версию с основного ответвления, невзирая на возможные метки и ответвления. Если от версии отходит ответвление, то оно также будет удалено со всеми собственными ответвлениями

rmver -vrange \main\1 \main\LATEST main.cpp

Удалить диапазон версий: от 1 до последней элемента main.cpp


rmview

Физическое удаление вида, для удаления необходимо указать путь до физического расположения View. Команда уничтожает логическое имя (тег) и очищает директорию vws, используемую видом. Для удаления можно использовать как физический путь, так и имя тега.

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


Rmviewftag Development

Удалить вид по его логическому имени

Rmview –f \\comp1\stg\views\Development.vws

Удалить вид по его адресу на носителе

rmview -vob \Sem -uuid 370c4440.76e311d6.a85c.00:a0:c9:3b:f1:04

Удалить все версии файлов, находящихся в состоянии check-out из репозитория \Sem. Удаляются только те версии файлов, которые принадлежат виду с идентификатором 370c4440.76e311d6.a85c.00:a0:c9:3b:f1:04. Данная команда используется администраторами, в тех случаях, когда в репозитории случайно остались файлы в состоянии check-out, зарезервированные за уже удаленными видами. Особенность ведения управления в СС заключается в том, что каждая версия элемента имеет уникальный uuid, основанный на имени того вида, в котором он редактировался или редактируется.


rmvob

Физическое удаление репозитория со всеми данными.

rmvob \\comp1\stg\vobs\vb.vbs

schedule

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

1) Редактируется файл …\ClearCase\var\scheduler\tasks\task_registry. В него вносятся задачи (tasks), в которых оговаривается наименование скрипта, подлежащего исполнению;

2) Редактируется файл …\ClearCase\config\scheduler\initial_schedule. В него вносятся необходимые виды работ (jobs), указывается периодичность и дается ссылка на конкретную задачу.

Более подробно смотрите в главе планирование действий по расписанию


Scheduleset initial_schedule

Установить все работы из указанного файла


setactivity

Установить или снять текущее действие в виде:


setactivity -c "demo" -view int_view act_int@\pvob1

Установить действие “act_int@\pvob1” в виде “int_view ”.


setcs

Установить в текущий или указанный вид конфигурационную спецификацию из заданного файла.


setcs -tag Rel1.0 –default

Установить для заданного вида конфигурационную спецификацию по умолчанию

setcs -tag Rel1.0 c:\r1.0

Установить для заданного вида конфигурационную спецификацию из файла c:\r1.0


umount

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


Umount -all

Размонтировать все репиозитории

Umount \Seminar

Размонтировать репозиторий с указанным именем


uncheckout

Вернуть элемент в предыдущее состояние. Команда является аналогом кнопки undo checkout из GUI. Измененный файл записывается как личный (private object) с расширением keep.


Uncheckout main.cpp

Провести команду uncheckout для файла main.cpp. Команда исполнится если файл уже находится в состоянии check-out


unlock

Снимает блокировку с элемента и делает его доступным для редактирования


Unlock main.cpp@@/main/0

Снимает блокировку с указанного файла, с версии 0


unreserve

Конвертирует статус элемента из нерезервного типа в резервный


Unreserved main.cpp


update

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


Updateall

Обновить данные во всех видах

Обоснование использования командной строки


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

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

Любые команды можно группировать вместе, создавая скрипты. Скрипт как полноценная рабочая единица может заниматься рутинными задачами, такими как насыщение, однотипными данными репозиториев или управление дополнительной политикой доступа к данным (см. триггеры). В качестве примера можно привести ситуацию с одним из заказчиков, которому было необходимо поддерживать версионность для WEB-портала. Суть заключалась в том, что портал состоял из ряда краткосрочных, но однотипных проектов (под однотипностью модно понимать метаданные VOB’а: одинаковые типы меток, ответвлений, атрибутов, триггеров… и и.д.). Единственным эффективным решением было не ручное повторение действий по созданию контента, а перепоручение их скрипту, который на основании команд СС будет создавать необходимый контент. Это общий случай использования командной строки. Рассмотрим основные случаи, в которых обосновано использование командной строки:


Управление правами на уровне элементов;

Управление триггерами, и формирование на их основе сложных логических действий, расширяющих стандартный СС;

Применение операций отката для случайно испорченного проекта;

Принудительное управление данными;

Формирование скриптов;

Создание распределенной структуры репозиториев;

Объединение команд разработчиков, работающих на разных платформ;

Объединение регионально удаленных команд разработчиков;

Формирование однотипного контента для множества репозиториев;

Любые действия по администрированию репозиториев и видов.

Управление действиями, выполняемыми по расписанию


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

В каких случаях оправдано применение собственных (пользовательских) расписаний? Какой вид работы нужно выполнять?

Дать универсальные советы сложно, поскольку у каждой компании своя специфика, но есть некоторый «джентльменский» набор, необходимый для полноценного функционирования:


Управление созданием архивных копий видов и репозиториев.

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


Управление сборкой и аудитом.

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



Управление действиями по созданию отчетов.

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


Историю изменений элементов;

Историю перекомпиляции проекта;

Статистику по слияниям;

Статистику по числу ошибок в разных версиях;

Статистику по версиям, находящимся в разработке;

Зачастую удобно, чтобы отчетностью управлял сам СС. Например, удобно и практично строить отчеты и публиковать их в виде WEB-страниц на внутрикорпоративном сайте компании для общего доступа к истории проекта. Второй плюс данного подхода заключен в том, что лицо ответственное за просмотр дел в проекте может не иметь установленного программного продукта. Просмотр ведется только средствами Internet Explorer’а (один из случаев, когда экономится лицензия на СС). Соответственно, как и в случае с компиляцией, генерация отчетов проводится в «ночном» режиме (если ежедневная) и в режиме выходных дней (если еженедельная).


Это основные рекомендации. Основываясь на них можно выстроить собственную технологию проведения работ по расписанию.

Из стандартных видов работ, встроенных в СС отметим основные:


Daily VOB Pool Scrubbing. Выполнение работ по чистке пулов данных

Daily VOB Snapshots. Обновление snapshot видов;

Daily View Space. Чистка видового пространства (удаление лишних элементов);

Daily VOB Space. Чистка пространства репозитория;

Daily MultiSite Export. Автоматический экспорт реплик;

Daily MultiSite Receive. Автоматический прием реплик;

Weekly Log Scrubbing. Чистка LOG-ов


Daily Local Tasks. Ежедневные пользовательские задачи;

Weekly Local Tasks. Еженедельные пользовательские задачи;


На все виды работ установлено расписание, по которому производится их активация. Если не вдаваться в детали, то для простого управления расписанием необходимо только оформить надлежащим образом Daily Local Tasks и Weekly Local Tasks.


Любое расписание составляется из задач (tasks) и работ (jobs):

Задачи представляют собой низкоуровневое звено в работе. Их задача – вызвать скрипт, реализующий физическое исполнение работы

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

Тем самым получается трехзвенное управление: работа (концепция) задача (запуск скрипта) скрипт (физическая реализация).


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


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

\Rational\ClearCase\var\scheduler\tasks\ccase_local_day.bat

\Rational\ClearCase\var\scheduler\tasks\ccase_local_wk.bat

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


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


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

Механизмы отчетности Clear Case


Представить современный мир информационных технологий (с его объемами информации) без отчетностей и сопроводительных документов практически невозможно. Многие программные системы имеют встроенные средства отчетности, есть системы профессиональной отчетности (Crystal Reports).

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

К сожалению, с профессиональными программами-генераторами Clear Case связи не имеет, но содержит ряд механизмов по созданию собственных отчетов.

Следует отделить две параллельные формы отчетности:


Встроенную, предоставляемую различными сервисами CC. В эту группу попадают все механизмы по получению отчетов: от команд командной строки, до собственных файлов отчетов, написанных на perl;


Внешнюю. К данному виду относится способ формирования отчетов на основе SoDA fo Word. Известно, что даны продукт способен формировать отчеты в виде DOC файлов и WEB страниц по данным из инструментов компании Rational (ClearCase один из таких инструментов. Более подробно о SoDA, читайте в соответствующей главе)


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

Рассмотрим доступные способы формирования отчетности:


Внешние:

Использование SoDA


Внутренние:

Использование встроенной системы с сохранением в виде Html

Использование командной строки для формирования элементарных отчетов

Использование языка скриптов для создания сложных форм отчетов

Использование работ и задач для формирования автоматизированной отчетности

Использование SoDA


SoDA является макросом для Word и отвечает за формирование отчетов в формате DOC и HTML на основе встроенных шаблонов. Инструмент позволяет пользователь формировать собственные шаблоны, основываясь на предустановленных, либо создавать произвольные с нуля (при помощи модуля template view).

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

Опишем стандартные формы отчетов:


Version - Отчет по версии одного элемента из репозитория ClearCase. Позволяет отобразить историю изменений и атрибутов для конкретной версии;


Vob Отчет по состоянию всех репозиториев в целом. Дает концептуальное представление о основных параметрах репозиториев, смонтированных в системе;


Element Отчет по свойствам элементов. Выводит информацию о состоянии версий, атрибутов, меток и ответвлений для одного элемента;


Region Отчет по всем используемым в проекте регионам. Дается информация по числу регионам, их именам и свойствам.


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

Более подробно о формировании отчетов в SoDA описано в соответствующей главе данной книги.


Использование встроенной системы с сохранением в виде Html


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

Модуль, отвечающий за отчетность, называется ClearCase Report Builder. Вызвать его можно из командной строки по имени ccreportbuilder (\Rational\ClearCase\reports), из меню системы StartProgramsRational Clear Case AdministrationClear Case Host Administration. CCRB также можно вызывать из браузера ClearCase Explorer.

На следующем рисунке показан фрагмент экрана с работающим Report Builder’ом

Врезка18

Работа в модуле сводится к выбору типов отчетов (в браузере слева) и их подтипа (вверху справа). Для генерации отчетов необходимо указать в навигаторе на файл, вид, репозиторий… и.т.д (в нижней правой части). Завершает процесс подготовки нажатие на Run Report. По введенным параметрам будет осуществлен поиск элементов и вывод их в оконном виде. Отчетные данные подлежат сохранению в виде Html файла.

Опишем основные типы отчетов, имеющих практическую ценность для проекта:

Elements

Check-ins Since Date by User. Отчет о версии элементов, которые были зарегистрированы в репозитории. Поиск осуществляется по имени пользователя и по дате. Удобный отчет по получению информации о вновь введенных файлов под управления. Поиск всегда ведется с использованием имени пользователя. Здесь учитывается особенность СС связанная с именами пользователей, в частности его чувствительность к регистру символов;


Elements Created By User. Список элементов созданных пользователем. СС сканирует репозиторий или директорию на предмет нахождения элементов, созданных конкретным пользователем;


Elements With File Name. Отчет по файлам директорий или репозитория. Поиск ведется по регулярному выражению (по маске). Удобно пользоваться дял поиска элементов с определенным расширением;


Version By date. Отчет по числу версий для каждого элемента репозитория;


Elements With Attributes. Отчет по элементам, которым присвоен определенный атрибут. Мы уже не раз упоминали о том, как удобно пользоваться дополнительным комментированием версий при помощи атрибутов. В предлагаемом отчете можно получить информацию о том, на каком файле находится атрибут (удобно при поиске элементов с атрибутом «tested»);


Element With Branches. Поиск элементов у которых есть ответвление;


Element With Multiple branch Level. Поиск элементов с множественным ответвлением;


Latest Version on Branch. Отчет по номерам последних версий на ответвлении;


Versions With Label. Отчет по номерам версий элементов, на которых имеется метка;


Elements With Trigger. Отчет по элементам, с установленными триггерами. Поиск осуществляется по имени триггера;

Vobs

All Vobs. Отчет по свойствам всех репозиториев;

Views

All Views. Отчет по свойствам всех видов


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

CCRB формирует отчеты на основе специальных скриптов, базирующихся на Perl, и построенных по специальным правилам. Это означает, что администратор проекта может добавлять новые скрипы в состав CCRB. Если вновь введенные файлы скриптов (просто скопированные файлы в директорию с CCRB) «распознаются» системой, то они встраиваются в окна генератора отчетов. Формат отчетов детально описан в документации.

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


Использование командной строки для формирования элементарных отчетов


Командная строка насквозь пронизывает ClearCase, позволяя получать доступ к любым видам данным. И, как одно из следствий, позволяют получать различные отчеты. В интерпретаторе cleartool есть целая группа команд групп lists – выводящих информацию о элементах, мета-данных и т.д.

Пользователь, работающий с СС всегда может получить простейший отчет, пользуясь хорошо известным приемом по перенаправлению вывода: это знаки «>» и «>>», проставляемые в конце командной строки, например:


cleartool lshistory main.cpp >> c:\report.txt

или

cleartool lshistory -user admin -a -minor -since 20-mar-99.15:00 >> c:\report.txt


Естественно, подобный подход очень примитивен, но представляется единственным мобильным способом. Некоторые команды cleartool предоставляют сервис форматного вывода (см. главу о командной строке) по переключателю –fmt, что позволяет получать быстрые отчеты надлежащего качества (команды annotate, describe).

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

Например, для формирования отчета Elements Created By User (имеющегося в стандартном наборе) собственными силами можно воспользоваться следующей командой:


Cleartool find . -elem "{created_by(Alex)}" -exec "cleartool desc %CLEARCASE_PN%"


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

Примитивность способа компенсируется его гибкостью. Мы в силах добавить нового пользователя к запросу:


Cleartool find . -elem "{created_by(Alex) && created_by(Administrator)}" -exec "cleartool desc %CLEARCASE_PN%"


После чего, СС начнет, на основании нового запроса, формировать отчеты.

Показанный способ позволит получить информацию по любым элементами и метаданным. Создать подобный отчет дело 1-2 минут.

Но, как всегда есть одно «но», демонстрируемый способ не позволяет, формировать качественные отчеты. То есть применять различные стили форматы по образцу, в данном случае невозможно, или слишком затруднено. Соответственно, репорты, полученные данным способом можно готовить только для внутреннего использования. Для выкладывания результатов на всеобщее обозрение этот способ не годится. Следующая тема ответит на данный вопрос.

Использование языка скриптов для создания сложных форм отчетов


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

Средствами только Perl можно создать скрипт, формирующий Html-документы, по результатам сканирования элементов репозитория. К преимуществам способа следует отнести:


Гибкость. Возможно создание любых отчетов;

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


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

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

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

Скрипт report_elem.pl


#################################################################

#

# Скрипт по формированию отчетов по элементам репозитория

# для выполнения скрипта необходимо создать директорию rep

# исправить переменную $name так, чтобы она смотрела на

# корневую директорию репозитория.

# Формат запуска скрипта: ccperl report_book.pl

# Результатом работы скрипта будет сформирован набор связанных

# HTML-страниц по каждому элементу.

# Скрипт подсчитывает сколько элементов всего врепозитории, собирает их

# свойства.

# Все элементы находящиеся в состоянии Check-out подсвечиваются красным цветом

#

################################################################


#Определяем переменную для подсчета числа версий файлов, находящихся в состоянии check-out

$nuco=0;


$versions=0;


#Полный путь до корневой директории репозитория

$name="Z:\\Sem\\";


#Формируем команду СС для поиска всех элементов с выводом данных

#на консоль

#Список формируется без вывода расширенной информации о

#элементе

$arg2="clt find $name -nxn -all -print";


#Счетчик числа элементов в репозитории. Счет ведем с 1

$objects=1;


#Формируем массив с заголовком для основного файла index.htm

$head="<HTML>

<HEAD>

<TITLE>Allo</TITLE>

<META http-equiv=\"Content-Type\" content=\"text/html; charset=windows-1251\"> </HEAD> <BODY bgcolor=#f3fff>

<CENTER> <b>Perl Script REPORT</b></font></center>";


#Формируем массив с заголовком для файлов, описывающих свойства

#элементов

$head2="<HTML>

<HEAD>

<TITLE>Allo</TITLE>

<META http-equiv=\"Content-Type\" content=\"text/html; charset=windows-1251\"> </HEAD> <BODY bgcolor=#f3fff>

<CENTER> **** FILE **** </font></center> ";


#Формируем массив с окончанием файла

$end="

</BODY></HTML>";


#Создаем Index.htm для записи

open(INDEX, ">Index.htm");


#Вписываем шапку html-файла

print INDEX $head;


#Формируем горизонтальную разделительную линию

print INDEX "<HR>\n";


#Формируем таблицу. Задаем тип линий и даем наименования

#колонкам

print INDEX "<TABLE width=\"100%\" border=2 cellspacing=3>\n";

print INDEX "<tr>\n";

print INDEX "<td> <b>ELEMENT</b>\n";

print INDEX "<td> <b>VERSIONS</b>\n";

print INDEX "<td> <b>NUM of CHECKOUTS</b>\n";


#Исполняем команду, находящуюся в массиве. Команда open

#перехватывает вывод сна консоль

open (FILE, "$arg2 |");


#Обрабатываем ответ, выводимый командой

while( <FILE> )

{

#Получаем построчно данные из потока и помещаем их в

#стринговую переменную

chomp;

@_ = split;

$buffer="@_";

#Формируем во временном стринге гиперссылку на файл

#с детальным отчетом

#по найденному сейчас элементу


$temper="<a href=\".\\rep\\$objects.htm\"> $objects). $buffer </a>\n";


#Открываем для создания и записи файл для детального

#отчета

open (OUT,">.\\rep\\$objects.htm");


#Вписываем в него заголовок

print OUT $head2;


#Формируем линию

print OUT "<HR>\n";


#Увеличиваем индекс объектов

$objects++;


#Записываем описание блока

print OUT "<b>DESCRIBE ELEMENT</b>\n";

print OUT "<br>\n";


#Исполняем команду получения описания элемента, адрес

#которого выл найден

#в предыдущих шагах (стринг $buffer)

open (DESC, "cleartool desc -l $buffer |");


#Получаем данные построчно

while( <DESC> ) {

chomp;

@_ = split;

#Вписываем в файл пробелы. Делаем принудительные

#отступы

print OUT "&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp\n";

#Пишем в него текщую строку

print OUT "@_ \n";

print OUT "<br>\n";

}

#Формируем следущий заголовок

print OUT "<br>\n";

print OUT "<b>VERSION TREE</b>\n";

print OUT "<br>\n";


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

open (DESC, "cleartool lsvtree -a $buffer |");


#Обнуляем счетчики версий

$versions=0;

$nuco=0;


while( <DESC> ) {

chomp;

@_ = split;

print OUT "&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp\n";


#Ставим условие. Если в строке есть

#слово CHECKEDOUT

#значит, что данный элемент выведен в

#данное состояние

#наша задача подсчитать число CO


if ( "@_" =~ "CHECKEDOUT" )

{

#Увеличиваем счетчик числа СО на 1

$nuco++;

#Делаем строку красного цвета,

#полужирной и выводим ее в файл

print OUT "<font color=\"red\">\n";

print OUT "<b>\n";

print OUT "@_ \n";

print OUT "</b><font color=\"black\">\n";

}else{

#Если условие не совпало

#выводим данные без выделений

print OUT "@_ \n";

}

print OUT "<br>\n";

$versions++;

}

#Формируем последний заголовок

print OUT "<br>\n";

print OUT "<b>ELEMENTS HISTORY</b>\n";

print OUT "<br>\n";


#Даем команду

open (DESC, "cleartool lshis -l $buffer |");


#Получаем ответ и просто вписываем в файл

while( <DESC> ) {

chomp;

@_ = split;

print OUT "&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp\n";

print OUT "@_ \n";

print OUT "<br>\n";

}


#Продолжаем формирование таблицы для файла с индексами

print INDEX "<tr>\n";

#Условие: если было подсчитано, что check-out больше

#нуля, то эти строчки

#целиком подсвечиваются красным фоном (цвет символов не

#меняем)

#В противном случае выводим в файл данные в соответствии

#со стандартными настройками


if ($nuco>0){

print INDEX "<td bgcolor=\"red\">\n";

print INDEX $temper;


print INDEX "<td bgcolor=\"red\">\n";

print INDEX "$versions";


print INDEX "<td bgcolor=\"red\">\n";

print INDEX "$nuco";


}else{

print INDEX "<td>\n";

print INDEX $temper;


print INDEX "<td>\n";

print INDEX "$versions";


print INDEX "<td>\n";

print INDEX "$nuco";

}

print INDEX "</tr>\n";

print OUT "<HR>\n";

print OUT $end;

close (OUT);

}

print INDEX "</table>";

print INDEX $end;

close(INDEX)

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

Следующие рисунки демонстрируют вид окна Internet Explorer, со статистической информацией по репозиторию Sem. Врезка19




Врезка20

Врезка21

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

Любая операция над СС требует лицензирования, соответственно, участники коллектива, желающие просмотреть статистическую информацию о состоянии элементов проекта, будут вынуждены «изъять» ее для проведения различных ревизий. Формирование же обновляемого отчета, с размещением его на сайте позволит сэкономить лицензию на не очень существенной операции, например, проводя генерацию отчета на сервере в конце рабочего дня или ночью.

В последнем случае выгодно создать задачу с именем «reports», сделать ее ежедневной, выполняемой в 3 часа ночи.


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


Планирование расписаний

Планирование расписаний из GUI

Врезка22

Графическая консоль позволяет:

Запустить имеющуюся работу;

Удалить имеющуюся работу;

Создать новую работу (при том, что уже предварительно создан нужный task, для ее осуществления, либо берется один из предопределенных);

Редактировать свойства имеющейся работы.

Экспортировать список работ в текстовый файл


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

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

Внести в вышеуказанные bat файлы скрипты, отвечающие за выполнение еженедельных и ежедневных работ

Создать новую работу с присвоением произвольного имени (либо подправить существующую)

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



Ежедневные работы имеют следующие настройки (рисунок 2):

Start Time. Время начала исполнения первой задачи. Берется серверное время

Start Date. Дата, после которой работа будет исполняться

End Date. Завершающая дата (может быть опущено, тогда работы буду выполняться бесконечно)

Repeat task. Число повторений работ (например, выполнить повтор работы через день, час, минуту… и т.д.)

Run Task. Тип выполнения (ежедневный, или через определенное число дней)

Врезка23

Еженедельные работы имеют следующие настройки (рисунок 3):

Врезка24

Start Time. Время начала исполнения первой задачи. Берется серверное время

Run Task. Тип выполнения (ежедневный, или через определенное число дней)

Days to run task. Дни запуска. Выбираются методом выделения дни, в которые работа будет исполняться

Start Date. Дата, после которой работа будет исполняться

End Date. Завершающая дата (может быть опущено, тогда работы буду выполняться бесконечно)

Repeat task. Число повторений работ (например, выполнить повтор работы через день, час, минуту… и т.д.)

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




Планирование расписаний из командной строки


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

Управление из командной строки можно разбить на 3 этапа:

  1. Составление скриптов, осуществляющих физическую реализацию работы;

  2. Редактирование списка задач, с целью создания новой;

  3. Редактирование списка работ, с целью создания новых


За рамками остается этап «запуск работы из командной строки».

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

По адресу:

Rational\ClearCase\var\scheduler\tasks\

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


Task.Begin

***”

TaskEnd – фрагмент, оговаривающий начало и конец описания задачи

Task.ID – идентификатор задачи. Это обычное число больше 100, поскольку диапазон номеров ниже данного порога зарегистрирован за системой (резерв)

Task.Name. Имя задачи. По данному полю задача вызывается из работы

TaskPathname. Путь к файлу, играющему роль скрипта.


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

Task.Begin

Task.Id: 102

Task.Name: "RunSpFile"

Task.Pathname: c:\1.bat

Task.End


Следующий шаг – создание работы. Для этого можно создать отдельный файл, с необходимым расписанием, а можно взять уже существующий файл initial_schedule, находящийся по адресу:

Rational\ClearCase\config\scheduler\

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


Job.Begin

Job.End – Обрамляет начало и конец блока описания работ;

Job.Name – Имя работы. Логическое имя можно сипользовать как из командной строки, так и из графических аплетов, рассмотренных выше (для визуальной модификации, например);

Job.Description.Begin

Job.Description.End - Блок, выделяющий произвольный комментарий на работу;

Job.Schedule.Daily.Frequency – Частота выполняемых операций по типам;

(Daily, Weekly, Monthly)

Job.Schedule.Start.DateДата старта;

Job.Schedule.Last.DateДата окончания. Абсолютная величина. Если поле не обозначено, то работа бессрочная;

Job.Schedule.FirstStartTime – Время первоначального старта в рамках указанной даты;

Job.Schedule.StartTimeRestartFrequency – Частота повторений (указывается интервал времени, например, каждые 2 минуты или 2 часа)

Job.Task – Имя вызываемой задачи


Рассмотрим пример работы, на базе уже созданной задачи



Job.Begin

Job.Name: "Woкk in my favorite job"

Job.Description.Begin:

Используется для тестового вызова

Job.Description.End:

Job.Schedule.Daily.Frequency: 1

Job.Schedule.StartDate: 3-nov-2002

Job.Schedule.LastDate: StartDate

#Работа на один день

Job.Schedule.FirstStartTime: 13:13:11

Job.Schedule.StartTimeRestartFrequency: 00:10:22

#Частота повторения работы (интервал перезапуска)

Job.Task: "RunSpFile"

Job.End


Как и во всех остальных текстовых файлов СС, знаком комментирования является «#».


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

Schedule –set Rational\ClearCase\config\scheduler\initial_schedule

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


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

COM и Rational ClearCase.

Модель многокомпонентных объектов (Component Object Model) лежит в основе большей части новой технологии MicrosoftActiveX, а после семи лет существования она стала неотъемлемой частью Microsoft Windows, - ведущим “индустриальным стандартом” программной архитектуры. Не странно, что Rational ClearCase поддерживает эту архитектуру. Для использования компонент COM в Rational ClearCase имеется библиотека – CAL(ClearCase Automation Library). Эта библиотека представляет собой COM интерфейс для получения доступа к данным ClearCase и манипулирования ими. CAL библиотеку можно использовать для написания скриптов, приложений и макросов для интегрирования в другие приложения. Стоит заметить, что для работы приложений, использующих CAL, необходима лицензия на ClearCase.

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


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

Как и для любого COM интерфейса, основными понятиями в CAL являются объекты, интерфейы, методы и свойства.

Обекты. На самом верхнем уровне CAL делится на множество различных объектов. Некоторые CAL-объекты представляют собой основные данные ClearCase, например, объект CCVersion используется для описания версий в ClearCase. Другие CAL-объекты являются объектами управления, напрямую не отражающие каких-либо явных данных ClearCase, но управляющие ими. Например, класс наборов (collection class) для объекта CCVersion управляет набором объектов типа CCVersion, объект CCCheckedOutFileQuery позволяет строить запросы для поиска файлов, находящихся в состоянии редактирования (checked-out files), объект TriggerTypeBuilder даёт возможность конструировать параметры для создания объектов типа триггер (trigger type objects). В CAL принято интуитивно понятное именование объектов – берётся имя из ClearCase и добавляется приставка “CC”. Например, в CAL объект CCElement представляет собой элемент ClearCase.

Интерфейсы. Стоит отметить, что различия между объектами и интерфейсами туманны для Visual Basic-программистов, но данные уточнения необходимы ввиду того, что далее приводятся примеры не только на Visual Basic, но и на Visual C++.

Объект может поддерживать несколько интерфейсов. Например, объект CCVersion поддерживает интерфейс ICCVersion для манипулирования информацией характерной версиям ClearCase и интерфейс ICCFile для манипулирования системной информацией о файлах. Так же различные объекты могут поддерживать один и тот же интерфейс. Например, объекты CCVersion и CCElement, оба поддерживают интерфейс ICCFile, потому что оба объекта представляют данные файловой системы.

Каждый CAL-объект имеет первичный интерфейс (primary interface), наряду с остальными (последние необязательны). В CAL множественные интерфейсы поддерживаются только через наследование, другими словами, если Вы знаете иерархию наследования, то Вы знаете какие интерфейсы поддерживает каждый объект. (Это не верно для всех COM-интерфейсов, но верно для CAL-интерфейсов).

Первичный (основной) интерфейс для CAL-объектов имеет то же имя, что и CAL объект, но с приставкой “I”. Например, объект CCLabel иммет основной интерфейс ICCLabel и объект CCVersion имеет основной интерфейс ICCVersion.

Методы и свойства. Каждый интерфейс поддерживает некоторое количество свойств и методов, посредством которых можно взаимодействовать с объектами. Свойства позволяют получить и (иногда) установить некоторую часть информации об объекте. Например, при помощи свойства Name интерфейса ICCLabelType можно получить имя объекта типа метка (label type object). Свойства по умолчанию (default properties) можно посмотреть в описании интерфейсов – они приведены в сводной таблице в начале описания каждого интерфейса. Visual Basic-программисты, ссылаясь на CAL-объект, могут опускать имя свойства, если они хотят получить доступ к свойству по умолчанию. Например, свойство по умолчанию для интерфейса IClearTool - CmdExec, итак, определив, Dim CT As New ClearCase.ClearTool, можно производить вызов CT("pwv"), что эквивалентно CT.CmdExec("pwv"). Метод совершает некоторое действие над объектом. Например, CheckOut – это метод объекта CCVersion, который позволяет поставить на редактирование (check out) версию.

Работа с CAL.

Разделяют две “стартовые точки” для взаимодействия с CAL: объект Application и объект ClearTool. Объект Application предоставляет максимальную API-функциональность CAL. Большинство приложений, использующих CAL, с помощью данного объекта создают другие объекты. Напротив, объект ClearTool имеет всего лишь один метод, CmdExec, который позволяет исполнять команды утилиты cleartool. Но использование объекта ClearTool оправдывается, т.к. возможности некоторых команд утилиты cleartool представляют собой решение многоэтапных задач, реализация которых через объект Application заняла бы значительный объём кода.

ClearCase.Application и ClearCase.ClearToolэто два единственных внешне-создаваемых объекта в CAL (и, соответственно, два единственных объекта, в названии которых нет приставки “СС”).

В COM-интерфейсах внешне-создаваемыми объектами называются такие, которые непосредственно создаёт клиент. В Visual Basic для создания объектов используется ключевое слово New, в C++ вызов CoCreateInstance() создаёт объект и в скриптовых языках объект создаётся вызовом CreateObject(). Большинство объектов CAL не являются внешне-создаваемыми и должны создаваться при помощи других объектов.

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

В Visual Basic-проекте из меню Project выбираем References. Здесь убеждаемся, что в списке выбрана библиотека ClearCase Automation Library x.x. Для получения объекта, представляющего ClearCase-версию M:\view\vob\file@@\main\3, создаём объект ClearCase.Application, затем получаем версию из объекта Application:

Dim CC as New ClearCase.Application

Dim Ver as CCVersion

Set Ver = CC.Version("M:\view\vob\file@@\main\3")

В этом примере использовался расширенный путь для обращения к версии. Но использование таких имён не обязательно. То пространство имён и связанный с ним синтаксис, что используется для работы в утилите cleartool или в какой-либо другой утилите ClearCase с графической оболочкой (GUI), также можно использовать и в работе с CAL. Например, если код был запущен в директории M:\view\vob и необходимо выбрать версию, имеющуюся в данном виде, то код может выглядеть следующим образом:

Set Ver = cc.Version("file")

После выолнения данного участка кода переменная Ver является CAL-объектом CCVersion представляющим M:\view\vob\file@@\main\3. Теперь Ver можно использовать для получения свойств этой версии. Например, для отображения версионного номера версии необходимо использовать следующий код:

MsgBox "Version Number " & Ver.VersionNumber

Как отмечалось выше, Visual C++ программисты должны получать доступ к объектам через соответствующие интерфейсы. Интерфейсы для внешне-создаваемых объектов – IClearCase (для ClearCase.Application) и IClearTool (для ClearCase.ClearTool).

Синтаксис. Синтаксическая нотация, используемая для работы с интерфейсами CAL, варьируется в зависимости от языка программирования. В справке (help) ClearCase можно найти информацию по синтаксису как для программистов на Visual C++ так и для Visual Basic.

В Visual C++ директива #import вызывает генерацию двух видов C++ “обёрток”- функций для библиотеки CAL (для работы с CAL в проект необходимо импортировать файл ccauto.dll, а затем воспользоваться директивой using namespace ClearCase):

Документированное описание существует лишь для “обёрток” высокого уровня.

Так же для каждого CAL-интерфейса определены “умные” указатели (smart pointer), например, ICCVersionPtr. Эти указатели управляют подсчётом ссылок на объект и автоматически освобождают память, когда удалены все указатели на объект. Описание (объявление) данных указателей можно найти в генерируемом файле cauto.tlh.

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

Посмотрим на простейшее использование объектов самого верхнего уровня – Application и ClearTool. (Всё дальнейшее изложение будет строиться на примерах для Visual C++) Работать с ними будем через “умные” указатели на соответствующие интерфейсы. Прежде всего, в создаваемом приложении необходимо инициализировать COM-библиотеку с помощью функции CoInitialize(). Затем уже можно работать с COM-объектами. Ниже приведена часть работоспособного кода, использовав который в своём приложении, можно исполнять команды утилиты cleartool и оперировать полученными данными ClearCase:

CoInitialize(NULL); //инициализация COM-библиотеки

CComBSTR output; //объявление стандартной для COM “двухбайтовой” строки

IClearToolPtr ctptr; //объявление указателя на основной интерфейс объекта ClearTool

try

{

ctptr = IClearToolPtr(CLSID_ClearTool); //инициализация указателя на интерфейс

output.Empty();

output.Attach(ctptr->CmdExec(L"lsvob")); //исполнение команды lsvob

//при помощи метода CmdExec объекта ClearTool

printf(output+"\n"); //вывод в консоль результатов исполнения команды

}

catch(_com_error & err) //обработка ошибок

{

output.Empty();

output.Attach(err.Description());

printf(output+"\n"); //вывод в консоль комментариев о произошедшей ошибке

}

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

Перейдём к более сложному (в плане использования) объекту Application. Рассмотрим также небольшой фрагмент кода:

try

{

IClearCasePtr ccptr = IClearCasePtr(CLSID_Application); //объявление и //инициализация указателя на основной //интерфейс объекта Application

ICCViewPtr ViewPtr; //объявление указателя на объект CCView

ViewPtr = ccptr->GetView(L"t_view"); //использование метода GetView объекта //Application для создания объекта CCView, //связанного с видом ClearCaset_view

output.Empty();

output.Attach(ViewPtr->GetConfigSpec()); //получение информации о конфигурации //соответствующего вида

printf(output+"\n"); //вывод полученной информации о правилах отбора версий для //данного вида “t_view

}

catch (_com_error& err) //обработка ошибок

{

output.Empty();

output.Attach(err.Description());

printf(output+"\n");

}

Как видим, специфика работы с объектом верхнего уровня CAL - Application состоит в том, что первоначально создаётся сам объект через объявленный на него указатель (IClearCasePtr ccptr = IClearCasePtr(CLSID_Application);), а затем, при помощи методов данного объекта, создаются “низлежащие” объекты (в данном примере – объект CCView). После этого уже можно вызывать методы созданных объектов.

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


 

Статьи

Данный раздел содержит статьи по программной инженерии, отечественным и зарубежным стандартам и методологиям, а также инструментальным средствам IBM Rational, Microsoft, Jira, Subversion.
Все статьи единым списком -->

 

Портфолио

Специалисты СМ-Консалт:

Наша компания является бизнес-партнером IBM и Microsoft и имеет статус Advanced IBM Partner.
Среди специалистов компании только сертифицированные профессионалы и эксперты, чей опыт и знания не вызывают сомнений.Нами выполнены и выполняются сложнейшие проекты и очень внимательно подходят к проблематике заказчика. За нашими плечами более 20 успешных проектов.За годы работы нами наработаны УНИКАЛЬНЫЕ решения, расширяющие и дополняющие инструментальные средства IBM Rational , что не раз помогало нашим клиентам решать самые сложные задачи.
Данный раздел содержит Резюме наших специалистов и их квалификацию и опыт работы, перечень наиболее значимых проектов, с отзывами заказчиков.