 | Уровень сложности: средний Евгений Соломаха, главный специалист отдела конфигурационного управления, СМ-Консалт
Александр Новичков, руководитель отдела внедрения и консалтинга, СМ-Консалт
07.04.2009 Статья рассчитана прежде всего на специалистов по конфигурационному управлению с применением инструментария IBM Rational ClearCase. В статье рассматриваются настройка (автоматизация) некоторых процессов, с которыми сталкивается специалист по ClearCase, а также практические и организационные моменты этой автоматизации. Статья, по сути, содержит алгоритм действий с описанием операций и команд по автоматическому созданию репозитория нового проекта по заранее определенному шаблону. Алгоритм, описанный в статье, можно рассматривать как единое целое, так же как разделяемые этапы, которые могут применяться в работе специалистами по конфигурационному управлению с использованием IBM Rational ClearCase.
Решение 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, поэтому не будет лишним при создании скрипта разделить его на самодостаточные модули и реализовать обработку аргументов для их успешной работы. Объединить скрипты можно скриптом-стартером, который будет последовательно выполнять каждый модуль и отслеживать успешность выполнения. Наверняка у Вас имеются в запасе собственные наработки, которые Вы применяете, поэтому представленный нами вариант не является постулатом и вполне может быть изменен с учетом особенностей вашего предприятия.
Ресурсы
Об авторах | | | Соломаха Евгений работает в области информационных технологий с 1992 года. Имеет опыт разработки прикладного, системного программного обеспечения, а также систем автоматизации. Имеет сертификаты по следующим продуктам IBM Rational: ClearQuest, UCM Fundamentals. Является главным специалистом отдела конфигурационного управления в компании СМ-Консалт (www.cmcons.com). |
| | | Новичков Александр работает в области информационных технологий с 1994
года. Является руководителем отдела консалтинга и внедрения IBM
Rational. Участвовал более чем в 20 успешных проектах внедрения IBM
Rational в таких организациях как Банк внешней торговли, ОАО «Татнефть»,
Национальный банк «ТРАСТ», Банк «Русский стандарт», ОАО «Иркут Авиа»,
ЗАО «АйТи», ЗАО «Аплана», Сбербанк России, Центральный банк Российской
Федерации, ОАО «Русский алюминий» и многих других. Имеет более 30
публикаций научных и научно-популярных материалов. Является
сертифицированным специалистом по следующим продуктам IBM Rational:
ClearCase for Windows, ClearQuest for Windows и UCM Essentials. За время
работы в консалтинге им обучено более 500 специалистов ведущих
IT-компаний России и СНГ. Является руководителем отдела внедрения и
консалтинга в компании СМ-Консалт (www.cmcons.com). Связаться с ним
можно по адресу rational.tools.info@gmail.com |
Выскажите мнение об этой странице
| |
