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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг № 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»
  
  
• «Управление метаданными репозиториев»
  
  
• «Конфигурационное управление проектами разработки программного обеспечения»
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Ресурсы
• Об авторах
• Комментарии