Александр Новичков
технический специалист Interface Ltd.
преподователь УЦ Interface Ltd.
Опубликовано в КомпьютерПресс 5'2001
Компания Rational Software является лидером в области создания методологий и программных решений, ориентированных на программистов, аналитиков, специалистов по тестированию приложений. Спектр выпускаемого обеспечения охватывает потребности всех участников проекта - от аналитиков до разработчиков и сотрудников, занимающихся внедрением готового продукта. Все программно-методологические решения - результат многолетнего труда аналитиков и разработчиков как самой компании Rational, так и ее партнеров и клиентов.
Все эти решения в совокупности составляют RUP (Rational Unified Process) - методологическую энциклопедию, в которой описаны все этапы создания качественного программного продукта. Пользуясь подобной энциклопедией и применяя соответствующие инструменты, рекомендуемые Rational, можно создавать программные продукты качественно и в срок.
Особое место в RUP занимает SCM (Source Code Management) - управление исходным текстом. SCM описывает способ контроля и сопровождения информации, составляющей программный проект. SCM - это методология, которую поддерживает продукт ClearCase, предназначенный для отслеживания и детального протоколирования всего, что связано с хранением всех артефактов, сопровождающих проект (здесь и далее термин "артефакт" следует трактовать как "хранимый документ". Работая над проектом, каждый участник создает определенный набор файлов-артефактов: документов, исходных текстов, бинарных файлов и т.д.).
При коллективной разработке проекта ClearCase рекомендован тем участникам проекта, которые должны обмениваться информацией с другими и точно знать, кто из коллег и когда вносил изменения. Ведь в современных условиях создания приложений большими командами разработчиков просто невозможно обойтись без надежного и мощного средства отслеживания изменений, позволяющего всем участникам команды представлять себе текущее положение дел в разработке проекта.
Рекомендованный как средство контроля версий при коллективной разработке проекта, ClearCase превосходно справляется с возложенной на него задачей. Являясь, по сути, масштабируемым приложением в архитектуре "клиент/сервер", ClearCase хранит всю возможную информацию, относящуюся к проекту, и позволяет получать последние версии редактируемых и архивных файлов (рис. 1).
Рис 1. Главное окно ClearCase. Одно из неоспоримых достоинств ClearCase - гибкость в настройке. Обратите внимание на русифицированные пункты меню - они созданы исключительно при помощи стандартных возможностей продукта.
С помощью уникального инвариантного подхода в этом продукте реализовано полное управление исходным текстом, включая контроль над версиями, управление рабочим пространством, конфигурацией среды и разрабатываемого ПО. Посредством ClearCase команда разработчиков совместно с руководителями подразделений и техническими писателями может сократить время поиска и анализа информации. Этот продукт позволяет убедиться в точности окончательных версий продукта, дорабатывать и поддерживать ранее реализованные продукты, организовывать эффективный процесс разработки - и все это без изменения среды, инструментальных средств и подхода к работе. Он обеспечивает управление версиями исходных текстов и библиотек на протяжении всего жизненного цикла проекта, позволяя разработчику вернуться к любой версии редактируемого файла и откорректировать его заново, создав новую версию.
Не секрет, что для многих компаний, выпускающих продукты для разных платформ, поддержание необходимого количества файлов для каждой платформы представляет серьезную проблему. Она усугубляется еще и необходимостью поддержки нескольких версий одного и того же продукта. В таких условиях любой существующий подход ведет к большим трудозатратам, существенно снижая производительность труда всего коллектива, поскольку большую часть времени в этом случае "съедают" различные согласования, отчеты, поиски нужных версий. Единственный правильный выход из сложившейся ситуации - это внедрение средства версионного и конфигурационного управления, способного разрешить данную проблему.
Имея в своем распоряжении ClearCase, каждый участник проекта получает доступ как ко всем файлам проекта, так и к определенной его части. Более того, при помощи специальных настроек один и тот же участник может получить доступ к конкретной версии файла из нужного проекта. Таким образом, при использовании ClearCase становится возможным редактирование абсолютно любых версий файлов, входящих в состав того или иного проекта. Для достижения подобного эффекта ClearCase использует мощную систему настраиваемых фильтров (в системе они называются ВИДАМИ - VIEWs), скрывающих ненужную информацию. Идеология программы достаточно проста: во-первых, любые изменения остаются в базе данных, во-вторых, в любой момент можно перейти к любой версии, если текущая содержит много ошибок (рис. 2).
Рис. 2. Создание вида. На этапе создания вида разработчик выбирает его тип и место хранения локальных служебных данных.
Система видов разительно отличает ClearCase от продуктов конкурирующих фирм, поскольку позволяет осуществить прозрачную работу и контроль над проектом. Что же такое вид? С точки зрения любого участника вид - это сетевой диск, на котором хранятся необходимые файлы. При этом полученные сетевые диски содержат последние версии проектных файлов, что, впрочем, не мешает перенастроить ClearCase таким образом, чтобы вид был сориентирован на отличную от текущей версию файла. Подобный подход делает систему разработки и поддержания нескольких версий не просто быстрой, а молниеносной (рис. 3).
Рис. 3. ClearCase Details. Основное окно при работе с данными. Здесь сосредоточены все управляющие элементы и подконтрольные данные. Дополнительно ClearCase поддерживает интеграцию и с обычным Эксплорером через систему контекстных меню.
Преимуществом ClearCase является также то, что данный продукт позволяет отдельному разработчику выходить из общего состава команды, забирая работу "на дом", а после всех внесенных изменений вернуть версии в проект. При этом ClearCase сам оповещает всех участников о том, что такой-то разработчик забрал на редактирование файлы.
Одним из мощнейших механизмов ClearCase является параллельная разработка, позволяющая нескольким разработчикам одновременно редактировать один и тот же файл. Проблема необходимости данного подхода вызывает столько же споров, что и вопрос множественного наследования в ООП. Конечно, общего рецепта не существует; в одних случаях такой подход оправдан, в других - нет. Однако на случай такой необходимости возможность ее реализации в ClearCase уже предусмотрена.
Кроме того, ClearCase позволяет объединять географически удаленные команды разработчиков посредством дополнительного модуля MultiSite, осуществляющего репликацию (передачу) текущего состояния проекта на указанный сайт. То есть если команда очень разбросана географически, то MultiSite позволит синхронизировать проект через Интернет для всех команд разработчиков.
В условиях бурно развивающейся и подверженной изменениям IT-индустрии становится все сложнее давать оценку программному продукту как чему-то независимому, вырванному из общего контекста разработки. Поэтому во внимание принимается степень поддержки данного продукта компаниями, создающими средства разработки. Так, продукт версионного контроля не может быть функционально полным без определенных механизмов интеграции со средствами разработки, с различными дополнительными генераторами отчетов и пр. (рис. 4).
Рис. 4. Окно дерева версий для одного файлового элемента. Каждый кружок представляет собой версию редакции, а красные стрелки указывают на объединение версий.
ClearCase обеспечивает тесную интеграцию с продуктами самой Rational (Rose, SoDA, ClearQuest, Requisite PRO), со средствами разработки и офисными приложениями компании Microsoft (Visual C++, Visual Basic, MS Word), а также с продуктами других компаний (более подробные сведения о вопросах интеграции и совместимости ClearCase со средствами разработки можно найти на сайте www.interface.ru).
Для реализации полного контроля над версиями в специальную базу данных - VOB (Version Object Base) - заносятся все изменения данных проекта.
Репозитарии, хранящие всю промежуточную информацию о состоянии проекта, могут находиться в локальной сети как на одном компьютере, так и раздельно. Физически VOB представляет собой некую файловую структуру, закодированную особым образом. Основой VOB являются элементы, представляющие собой файлы или каталоги. Элемент должен и может иметь одну или несколько версий.
Все элементы VOB имеют свою уникальную версию. При создании VOB получает определенный набор характеристик, на основании которых в дальнейшем можно определить (при наличии соответствующих полномочий) историю его создания. Над VOB можно осуществлять операции монтирования/демонтирования, создания/удаления. Для работы с конкретным репозитарием каждый участник монтирует его на своем компьютере.
Создания одной только базы данных для полноценной работы в ClearCase недостаточно, необходим также клиент для доступа к ней. Для всех манипуляций над базой данных, в соответствии с правами пользователей, применяется механизм настраиваемых видов (VIEW), являющийся технологическим средством фильтрации находящейся в VOB информации и преобразующий все подмножество элементов со своими версиями в вид, понятный не только машине, но и человеку. Такой подход позволяет разработчику или техническому писателю видеть не все файлы, составляющие проект, а только необходимые для решения конкретной задачи. Таким образом, ClearCase позволяет достаточно легко абстрагироваться от текущего состояния и сосредоточиться на определенной части проекта.
Исключительно через систему видов возможны все операции, присущие не только ClearCase, но и любому другому средству версионного и конфигурационного контроля, такие как установка контроля файла (Add To Source Control), при котором для каждого элемента создается дерево версий, операции Check-in и Check-Out, позволяющие редактировать отдельный файл, создавая дерево версий, на котором отражена полная история развития отдельного элемента (рис. 5).
Рис. 5. История редактирования файла.
Помимо этого ClearCase обеспечивает менеджеров проекта и разработчиков специальным модулем отчетности, с помощью которого можно получать справочную информацию об истории редактирования того или иного элемента в отдельности или группы элементов. Отчет может быть экспортирован в Microsoft Word (посредством инструмента SoDA), выведен на экран или опубликован в Интернете.
Виды в программе представлены двумя типами - Dynamic и Snapshot, имеющими свои достоинства и недостатки, но при совместном использовании способными открыть новые возможности в контроле над файлами.
Специфика вида Dynamic заключается в том, что данный вид (Windows NT, UNIX) создает виртуальную файловую систему, на которой размещаются все подконтрольные данные. Сама файловая система размещается также на виртуальном диске, физически размещенном на сервере. Для конечного пользователя в этом случае работа с таким видом сведется к работе с новым сетевым диском.
Данный способ позволяет осуществлять контроль над файлами в реальном масштабе времени. Основные преимущества данного способа представлены перенастраиваемыми видами. Эффективность использования особенно ярко проявляется Dynamic View в случаях, когда менеджерам необходимо одновременно контролировать несколько проектов, либо для настройки конфигураций, когда необходимо поддерживать одинаковые версии исходных файлов для разных операционных систем.
Вид типа Snapshot оправдывает свое название, создавая "снимок" текущего состояния проекта на локальной машине. Разработчик получает на своем диске точную копию либо всего проекта, либо необходимой его части - файла, группы файлов: Важным моментом при такой работе является синхронизация локальных данных с общим проектом, которая в данном случае выполняется не автоматически, а по команде пользователя. Это делает возможной удаленную работу над проектом, позволяя любому разработчику взять материал "на дом", после чего вернуть новые версии файлов в проект.
Имея мощный набор инструментов, настраивающих вид, можно добиться поразительных эффектов, недоступных для других программ версионного контроля. Неоценимой является возможность параллельной разработки, когда программа допускает правку одного и того же файла несколькими разработчиками, создавая ответвление на дереве версий (одно или несколько - в зависимости от числа разработчиков, использующих данный файл).
Как уже говорилось ранее, для каждого файла создается дерево версий. Дерево состоит из корня и версионных ответвлений. Здесь следует отметить две разновидности ответвлений: простое ответвление (Branch), создаваемое для отдельного файла и в любых количествах, и главное ответвление (Private Branch) - для всего проекта, когда создается новая ветвь (может быть только одна) для всех файлов, составляющих проект.
Для объединения версий в ClearCase предусмотрена специальная утилита - MergeManager - менеджер слияний, который под контролем менеджера проекта собирает из двух предоставленных файлов один. Сборка осуществляется либо автоматически (тривиальная сборка), когда различия между файлами невелики, либо по выбранной менеджером проекта строке кода для слияния (нетривиальная сборка). По окончании слияния создается новая версия, которую далее также можно править, объединять с другими версиями, делать ответвления.
Слияние файлов можно производить как из ClearCase, так и из командной строки. Допускается слияние только текстовых файлов.
Из важных возможностей ClearCase следует также отметить создание видов на базе профилей, что может слегка усложнить и дерево версий, и понимание самой программы, зато позволяет особым образом настраивать систему видов для каждого участника проекта в отдельности: для разработчиков настройки могут быть одними, для сотрудников, ответственных за тестирование, - другими.
Программа обладает развитым интерфейсом и полностью использует возможности современных операционных систем. Для обеспечения максимальной производительности ClearCase (помимо графического интерфейса) имеет широкий набор команд для работы из командной строки.
Особо хочется отметить возможность сборки проекта. При помощи утилиты OMake возможна сборка проекта в исполняемый модуль. Утилита работает из командной строки и не зависит от типа используемого компилятора, главное - чтобы его можно было вызвать из командной строки. При этом сценарий сборки базируется на обычных make-файлах.
ClearCase относится к той группе инструментов, которые при своих весьма широких функциональных возможностях все же неспособны полностью раскрыть их без интеграции со средствами разработки. ClearCase может быть совместно использован с таким популярным средством разработки, как Visual Studio.
Совместное использование этих двух продуктов обеспечивает дополнительную возможность управления версиями непосредственно из среды разработки. ClearCase встраивается в рабочее пространство VisualStudio, дополняя своими функциями меню программы.
Таким же образом интеграция происходит с Microsoft Word и Microsoft Front Page. В последних двух случаях появляется возможность слияния не только текстовых файлов, но и файлов с расширением DOC, XML, HTML.
В этих пакетах встраивание выглядит так же, как и в Visual Studio, - все функции контроля версий доступны через их главное меню.
Компания Rational посредством RUP регламентирует все этапы разработки программного обеспечения, объединяющего в себе все знания и опыт. Для каждого из приведенных в RUP этапов компанией Rational создано специальное програмное обеспечение, в частности ClearCase. Расширив его за счет некоторых программных продуктов или дополнительных модулей, можно получить некоторые дополнительные возможности.
Рассмотрим продукты и модули, которые можно использовать совместно с ClearCase.
Рис. 6.
Все современные средства коллективной разработки Rational обладают Web-интерфейсом, что само по себе очень логично в условиях территориально разбросанной команды и удаленного доступа части сотрудников. Особая необходимость в использовании Web-интерфейса как раз и открывается при распределенной разработке (рис. 7).
Рис. 7. Здесь приведено начальное окно, где пользователь выбирает локально хранимые данные проекта и имя вида, к которому производится подключение клиента.
Интерфейс приложения прост и понятен, способ работы также не вызывает сложностей: все необходимые для работы файлы переносятся на локальный компьютер и модифицируются любым известным способом. Доступ к тем или иным файлам репозитария осуществляется посредством выбора соответствующего вида, предварительно физически созданного на сервере (например, отдельный вид для разработчиков, технических писателей и т.д.). Отредактированные файлы возвращаются обратно в систему. Web-доступ организуется c помощью Internet Information Server или Web-серверов Netscape (рис. 8).
Рис. 8. Так выглядит окно работы с проектами. В верхней части браузера - наименования доступных в данный момент операций.
Многое из вышеоописанного, возможно, уже знакомо читателям, применявшим сходные средства контроля и управления.
Хочется еще раз отметить особенность использования ClearCase в Windows NT: этот продукт обладает мощным графическим пользовательским интерфейсом и мощным интерфейсом командной строки. Соответственно каждая операция может быть выполнена двумя различными способами. Командная строка позволяет подстраивать продукт под конкретные нужды конкретной компании. Без помощи командной строки достаточно сложно произвести некоторые тонкие настройки, имеющие отношение к работе с данными.
Каждая операция, производимая над данными, предварительно описывается как значимая и неделимая. Набор таких описаний и правил носит название Configuration Management и является частью методологии RUP.
Configuration Management полностью регламентирует, что, как и кем должно делаться в проекте и как использовать для этих целей ClearCase. Согласитесь, мало иметь инструмент, нужно уметь им пользоваться.
Попытаемся рассмотреть (схематично), каким образом 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. Обратите внимание: первая версия для данного вида стала текущей, а самой версии назначено две метки (ClearCase позволяет поставить и больше - для тех случаев, когда одна и та же версия файла переходит из одного релиза в другой без изменений).
Можно, например, включить в фильтр все файлы с расширением BAT с нулевой версией, тогда правило будет иметь следующий вид:
Или можно настроить ClearCase так, чтобы выводились файлы строго определенного типа (в ClearCase, как и в жизни, расширения могут различаться, а типы файлов совпадать, например, архивные файлы). Правило будет выглядеть так:
Или просто отсортировать все файлы по дате или/и времени "...\bugfix\LATEST -time yesterday",
И самое главное: ClearCase позволяет создавать архив правил в виде отдельных файлов, которые можно загружать директивой Include.
Таким образом, одну и ту же функцию продукт способен выполнить несколькими способами. И здесь нельзя сказать, что один способ лучше, а другой хуже - все они одинаково полезны. Сам проект только выиграет, если все способы будут применяться одновременно.
Разработчик может создавать различные ответвления версий своих файлов исключительно для собственного удобства, делая ответвления командой mkbranch, менеджер проекта совместно с разработчиком ставит метку с номером сборки проекта на конкретную версию. Если необходимо осуществить редактирование одного файла силами более одного человека, то прибегают к помощи MergeManager и профилей. А для создания сборок пишут правило ConfigSpec (Configuration Specification), по которому будут выводиться файлы.
Отличительные черты ClearCase
Спецификации
Требования для клиентской части:
Требования для серверной части:
Поддерживаемые Web-браузеры:
Поддерживаемые Web-cерверы
Поддерживаемые операционные системы
Интеграция со средствами разработки:
ClearCase на сегодняшний день является самой продвинутой системой версионного и конфигурационного управления, снабженной новейшими достижениями в области SCM (Source Code/Configuration Management). Поскольку ClearCase является системой корпоративного уровня, рекомендовать ее можно всем предприятиям, число разработчиков в которых больше пяти. Продукт можно изучить на курсах. Все мощные возможности ClearCase раскрываются при использовании его на крупных предприятиях с большим количеством разработчиков. ClearCase - поистине незаменимый продукт, когда речь заходит об объединении регионально удаленных команд разработчиков.
Более полная информация о продукте доступна на сайте www.interface.ru
По вопросу получения ознакомительной версии обращайтесь по e-mail
element * CHECKEDOUT
element * REL1
element * CHECKEDOUT
element * REL1
element *.bat /main/0
element * CHECKEDOUT
element -eltype archive * REL1
time 10-Jul.19:00 element \atria\lib\* ...\new\LATEST element * \main\LATEST end time
Справочная информация
Заключение