Рубрики

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

Автоматизация при создании рабочего пространства в среде IBM Rational ClearCase

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




CC

CC

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

Статья родилась в результате работ с нашими заказчиками. После публикации на сайте IBM я про нее немного забыл :)

Авторы: Александр Новичков, Евгений Соломаха

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

А теперь давайте представим себе, что подобных людей в проекте может быть несколько, или подобная работа повторяется? И что в итоге? Задача-то будет выполнена, но как скоро и с каким качеством?

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

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

Из чего же состоит весь этот процесс подготовки и создания репозитория? И здесь все достаточно прагматично и просто, давайте рассмотрим все по порядку.

Имя VOB (репозиторий, хранящий версии файлов и директорий, результаты сборки и ассоциированные с ними метаданные). Прежде всего и здесь наверняка присутствует необходимое определение/ограничение в рамках плана управления конфигурациями (УК), и наверняка это заведомо определенная аббревиатура продукта разработки. Кстати, эта характеристика (аббревиатура) может и, наверное, должна использоваться в смежных системах, таких как RequisitePro, ClearQuest и т.п., участвующих в жизненном цикле (ЖЦ) продукта разработки программного обеспечения (ПО).

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

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

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

Ветки (Branch). Набор имен веток, в которых будет вестись разработка/доработка проекта. Обычно этот набор или правила создания регулируются тоже планом УК. Этот набор не очень сложен, но автоматизация его тоже не помешает.

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

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

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

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

Процесс описан, дело за малым – рассмотреть возможность автоматизации каждого из шагов.

Шаг № 1. Создание VOB. Реализуется с помощью стандартной команды

cleartool.exe mkvob –tag ‘TEST1’ –c “Репозиторий ТЕСТОВЫЙ” ‘\\Server1\VobStorage1\TEST1.vbs’

Шаг № 2. Создание временного рабочего представления (View), требуется для выполнения следующих шагов, так как выполняется из области View:

Cleartool.exe mkview –tag ‘Admin_TEST1’ ‘\\Server1\ViewStorage1\Admin_TEST1.vws’

Затем стартуем представление:

cleartool.exe startview ‘Admin_TEST1’

И далее монтируем созданный ранее VOB:

cleartool.exe mount TEST1

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

Шаг № 3. Создание триггеров. Также реализуется достаточно просто:

Cleartool.exe mktrtype –element –nuser 'Admin' –c «Проверка заполнения комментария при операции CI» –all –preop checkin –exec «ccperl '\\Server1\Triggers\tr_filldesc_ci.pl» v_filldesc_ci'

Шаг № 4. Создание меток. Выполняется с помощью стандартной команды:

Cleartool.exe mklbtype –c «Метка для ветвления в основной поток разработки – DEV» PR_0.0.0'

Шаг № 5. Создание веток. Выполняется стандартной командой:

Cleartool.exe mkbrtype –c «Основной поток разработки» DEV

Шаг № 6. Создание типов элементов. Выполняется стандартной командой во вновь созданном VOB для каждого типа файлов, использующихся в проекте:

Cleartool.exe mkeltype –supertype text_file –mergetype auto –c \”Исходные тексты С\” c_source”

Шаг № 7. Создание шаблонов View. Эта операция по сравнению с предыдущими операциями нетривиальна, но вполне выполнима. Не останавливаясь на детальных подробностях, скажем, что профиль состоит из текстовых файлов и может быть создан с применением скриптового языка. Но нужно иметь в виду, что у каждого объекта ClearCase есть Globally Unique Identifier (GUID), детально об этом можно узнать здесь: http://ru.wikipedia.org/wiki/GUID). Сформировать его тоже не является серьезной проблемой, например можно воспользоваться утилитой Uuidgen.Exe.

Шаг № 8. Создание структуры проекта. Задача не составляет труда и полностью реализуется системными командами или скриптом. Затем созданная в области View структура ставится под контроль.

Шаг № 9. Определение прав доступа в рамках ранее созданной структуры. Реализуется с помощью стандартных команд ClearCase.

Добавление групп пользователей – cleartool.exe protectvob –f –add prj_TESTERS TEST1

Изменение прав на элементы версионного контроля и структуры каталогов – cleartool.exe protect –recurse –chgrp prj_TESTERS –chmod 777 TEST1 или cleartool.exe find . –name «src» –nxn –type d –exec 'cleartool protect –recurse –chmod 770 %CLEARCASE_PN%'

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

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

Ресурсы:

 

Автоматизация при создании рабочего пространства в среде IBM Rational ClearCase, 10.0 out of 10 based on 1 rating
Срочный ремонт переключателя скоростей велосипеда в веломастерской Велодоктор..

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

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

Leave a Reply

 

 

 

You can use these HTML tags

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

Spam protection by WP Captcha-Free