СТАТЬЯ
21.01.02

Первые шаги в UCM

© Костиков А.В.

Содержание

Введение

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

Рис. 1

Чтобы не запутывать читателя второстепенными вопросами, я буду рассматривать простейшую команду, состоящую из менеджера проекта и разработчика. Функции интегратора будет выполнять менеджер проекта. Для наглядности проект будет представлять собой разработку консольного приложения для Windows. Среда разработки - VisualStudio (VS). Тем самым я постараюсь рассмотреть тот минимум знаний, который необходим для интеграции RationalClearCase с MicrosoftVisualStudio.

Интеграция c Microsoft Visual Studio

Во-первых, в используемой совместно с ClearCase среде разработки должна выполняться компиляция из командной строки (На одном из последних этапов установки VS надо зарегистрировать переменные среды в операционной системе). Это необходимо для использования утилиты omake. Во-вторых, надо добавить в VS кнопки вызова утилит ClearCase. Это делается следующим образом:

Start -> Programs -> Rational ClearCase Administration -> Integrations -> omake Integration Configuration.

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

Создание проекта
(Я рассматриваю случай, когда проект создаётся “с нуля”)

Создание проекта в UCMначинается с создания репозиториев, в которых будет храниться вся информация о проекте, будь то сведения о потоках, действиях, наборах изменений или информация о видах, элементах. Для полноценного проекта необходимо минимум два VOB’а: проектный VOB (PVOB) и компонентный VOB. Для этого в утилите ClearCaseHomeBase необходимо нажать кнопку “CreateVOB”. В этом случае мастер поможет Вам корректно создать репозиторий. В первую очередь создаётся VOB проекта (PVOB), в котором будет храниться информация о UCM-объектах.

Для этого в первом окне мастера необходимо поставить галочку в поле “CreateasaUCMprojectVOB”, а галочку в поле “CreateasaVOBlevelcomponent” (создать VOB как компонент) надо убрать. Проектный VOB назовём pvob1 (фрагменты этого окна представлены на рис. 2).


Рис. 2

В одном из следующих окон мастера для вновь создаваемого проектного VOB’а надо указать, что он не имеет административного репозитория (Рис. 3).

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


Рис. 3

абсолютно наоборот. Компонентный VOB назовём vob1. А в окне с вопросом, какой VOB будет административным для создаваемого репозитория, необходимо выбрать pvob1.

После этого этапа у нас уже имеется как бы скелет для будущего проекта – место, где ClearCase будет хранить всю информацию. Осталось наполнить проектный VOB данными о проекте, который ещё не существует физически. Чтобы наполнить PVOB минимальным набором необходимых данных, надо запустить ProjectExplorer, и создать в PVOB’е проект. Делается это выбором в контекстном меню объекта pvob1 пункта New->Project (Рис. 4).

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

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

На четвёртом шаге мастера (NewProjectStep4) обязательно надо сделать компоненту изменяемой  (Рис. 5).

Рис. 5

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

Итак, создадим вид интегратора. Инициировать этот процесс можно из ProjectExplorer’а. Для этого в контекстном меню объекта project1_integration надо выбрать пункт “CreateView”. Опять же, запустится мастер, который уже знает, что Вы хотите создать вид интегратора. (Я заранее считаю, что все создаваемые виды – динамические, в этом случае можно использовать большинство удобных возможностей ClearCase, отличающих его от конкурентов).
Теперь можно создавать файлы для постановки их под контроль. Посмотрим, как это сделать при помощи среды разработки VisualStudio. А именно, создадим консольное приложение “Hello, World”, сохранив его в виде интегратора (на диске MVFS). Поставить под контроль созданные файлы можно из того же VisualStudio. Для этого надо выделить все текстовые файлы проекта (имеется в виду проект VisualStudio) и в их контекстном меню выбрать пункт “Addtosourcecontrol” (Рис.6). В первом же окне мастера необходимо поставить галочку в поле “Keepcheckedout”, чтобы избавиться от лишнего действия – отдельного выведения файлов на редактирования (“checkout”). После того, как Вы нажали “Ок” – согласились поставить под контроль выделенные файлы, Вам предложат выбрать действие, с которым будет ассоциироваться

Рис. 6

постановка под контроль файлов. В условиях данного примера необходимо создавать новое действие: кнопка “New”в окне выбора действия (Рис. 7).

Рис. 7

Я назвал это действие для наглядности “add”. После окончания работы мастером, файлы являются уже элементами компонента, т.е. частью проекта. Нетрудно видеть, что элементы проекта выведены на редактирование под тем же действием – “add”. Теперь можно вносить изменения в файлы, которые сохранятся на диске MVFS. После этого надо исправленные файлы записать в VOB, тем самым вывести из состояния редактирования. Это делается командой checkin. В данной ситуации удобно снимать с редактирования (“checkin”) одновременно все файлы проекта VisualStudio, подобно тому, как ставили их под контроль. Чтобы не возникло ошибки при операции “checkin” с неизменёнными файлами, в первом окне мастера надо в опции “Advanced” поставить галочку в поле “Checkinevenifidentical” (Рис. 8).

Рис. 8

После того как новые элементы зафиксированы в VOB’е, можно создавать рекомендованную базовую линию, содержащую эти файлы (правильнее сказать – данные версии этих файлов). Запустить соответствующего мастера можно из ProjectExplorer, выбрав в контекстном меню потока слияний пункт “MakeBaseline”. На первой закладке первого окна можно изменить имя базовой линии, если у Вас уже есть система именования базовых линий (в данном примере эту базовую линию я назвал BL1). На второй закладке этого окна можно посмотреть и выбрать нужные сданные действия, на основании которых построится базовая линия (в случае моего примера – add). Для более “прозрачного“ наполнения новых потоков необходимыми файлами, необходимо созданной базовой линии назначить статус рекомендованной. Опять же, в контекстном меню потока project1_integration выбираемпункт Recommend Baselines. В первом окне мастера старую базовую линию vob1_initial надо удалить (кнопка “Remove”), и добавить новую (соответственно “Add”). После нажатия “Add” надо выбрать созданную базовую линию – BL1.

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

Создать поток разработчика, а вместе с ним корректно настроенный вид, удобнее всего, запустив соответствующего мастера из ClearCaseHomeBase -> Projects -> JoinProject. Сначала надо выбрать проект, к которому Вы хотите присоединиться (Рис. 9).

                    

                     Рис. 9

В следующем окне выведены два названия потоков – верхний, разработчика, - который Вы создаёте, и нижний – поток слияний – тот поток, в который будут сдаваться действия из создаваемого потока. Соответственно, создаваемый – Sash_project1_dev_str, и поток слияний – project1_integration (Рис. 10). После завершения ещё нескольких стандартных для ClearCase операций (имя создаваемого вида, выбор буквы для диска MVFS, разрешение-запрещение создания общедоступных DerivedObject’ов), будет создан поток и вид разработчика (в примере соответственно Sash_project1_dev_str и Sash_project1_dev_view). Существование этих объектов можно обнаружить следующим образом: поток разработчика появится в древовидной структуре потоков в ProjectExplorer, а новый диск MVFS (Sash_project1_dev_view) отобразится, например, в ClearCaseExplorer.

Рис. 10

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

Рис. 11

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

Компиляция проекта с помощью утилиты omake

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

Первоначально компилировать проект c помощью утилиты omake будем в виде интегратора, получив результатом компиляции кроме exe-файла ещё и DerivedObjects (DO) – файлы с информацией о компиляции. Затем, предоставим их в совместное пользование – в рассмотренном примере – в вид разработчика. Чтобы выполнить такую “обычную” операцию – собрать и откомпилировать проект с помощью утилиты omake, необходимо предоставить  описание вашего проекта в определённом формате, поддерживаемом данной программой. Это так называемый makefile (файл *.mak).  Это можно делать следующим образом: открываете проект в VS (из вида интегратора), и в главном меню VS: Project -> Export Makefile (Рис. 12).

Рис. 12

После этого в директорию с файлами проекта будет помещён makefile (в моём примере – это файл “test.mak”). Теперь можно производить и непосредственно сборку с компиляцией – для этого необходимо выбрать следующую опцию в меню VS: Tools->omake. Увидеть результат работы утилиты можно с помощью команды “lsdo”. Для этого в командной строке ClearCase (утилита cleartool) необходимо зайти в директорию, созданную VS после компиляции – Debug (она находится в директории с проектом). Набрав команду “lsdo” для просмотра объектов компиляции omakeDO, можно увидеть файлы, созданные утилитой. Командой “catcr “ можно посмотреть содержимое DO. Не буду сейчас отдельно останавливаться на содержании информации о компиляции в DO, т.к. целью рассмотрения omake является предоставление этих файлов в совместное использование (sharedDO) из других видов.
Для осуществления этого, во-первых, необходимо, чтобы древовидные структуры директорий с файлами проекта были одинаковы в тех видах, между которыми происходит “обмен” DO. В рассматриваемом примере – необходимо существование директории Debug в директории с файлами проекта  – как в виде разработчика, так и в виде интегратора. (Упомянутая директория создаётся средой разработки при компиляции проекта, т.е. если проект компилировался в обоих видах, то можно не заботиться о доработке древовидных структур проекта на дисках MVFS.) Во-вторых, необходимо “повысить уровень” DO до доступных в совместное пользование (shared) – собственно произвести предоставление в совместное пользование. Это делается из командной строки утилиты cleartool с помощью команды winkin. Удобнее всего эту команду исполнять в той директории, где находятся DO, которые Вы хотите предоставить в совместное пользование. Хочу сразу предостеречь пользователей ClearCase, кто не имеет достаточного опыта, от набора укороченных имён элементов VOB (winkintest.exe).Иногда в связи с этим могут возникнуть ошибки. Более правильно исполнить команду с версионно-расширенным именем файла: winkin test.exe@@18-dec.01:54.155. Если исполнение команды завершено без ошибки, то, зайдя из cleartool в директорию Debug вида разработчика, и, набрав команду “lsdo”, можно увидеть DO предоставленные в совместное пользование (sharedDO).

Более подробное описание утилиты omake и команд для работы с DO можно найти в ClearCaseHelp и в документации, поставляемой с ClearCase.

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

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме Rational Software
Отправить ссылку на страницу по e-mail


Interface Ltd.
Тel/Fax: +7(095) 105-0049 (многоканальный)
Отправить E-Mail
http://www.interface.ru
Ваши замечания и предложения отправляйте автору
По техническим вопросам обращайтесь к вебмастеру
Документ опубликован: 21.01.02