Заметки консультанта

Шамрай Александр Владимирович

Сравнение концепции ClearCase UCM и RTC

Posted by Шамрай Александр на Ноябрь 15, 2010

Оригинал: Comparing concepts between ClearCase UCM and RTC

Введение

Некоторые путаются в сходствах и различиях между Rational ClearCase и Rational Team Concert. В основном это связано с изменениями в терминологии, а в некоторых случаях это связано с различными моделями использования и возможностями продуктов. Данная статья направлена на прояснение некоторых моментов.

Демонстрация будет выполняться на основе UCM, так как многие из наших клиентов используют ClearCase UCM. Если вы используете ClearCase UCM интегрированный с ClearQuest, то настоятельно рекомендуется также прочитать Сравнение концепции ClearQuest и Rational Team Concert.

Базовая терминология

Давайте рассмотрим различия между ClearCase UCM и Rational Team Concert (RTC). ClearCase является системой управления конфигурацией. Клиенты могут использовать его отдельно или с функциональностью UCM. UCM дает пользователям создавать программные Компоненты (Component), а затем создавать Базовые линии (Baseline) на эти компоненты. Файлы для изменения Извлекаются на редактирование (Checked Out), изменяются, а затем Регистрируются (Checked In) в рамках представления, которое является рабочим пространством для разработки. Наборы изменений (Change Sets) составляются из отдельных изменений, внесенных в рамках Активности (Activity). Эти Наборы изменений затем становятся общедоступными для других членов команды через операцию Доставки (Delivery) этих Наборов изменений. ClearCase хранит эти артефакты в собственном формате и сохраняет все свои данные в репозитории, который называется VOB. Каждый VOB может содержать один или более компонентов UCM. Каждый VOB может хранить артефакты в любой структуре каталогов, которую пользователь хочет использовать. ClearCase поддерживает параллельную разработку и, когда возникают конфликты между версиями одного и того же файла, то они разрешаются с помощью операции Слияния (Merge). В базовом ClearCase, VOB-файлы могут содержать Ветви (Branch), которые обеспечивают логическое «разделение» кода для параллельной разработки, которая выполняется изолированно. В UCM эти Ветви имеют некоторые формальные ограничения и называются UCM-потоки (UCM Streams). Участник команды разработки выполняет Доставку его или ее изменений из их рабочего пространства, называемого Представлением (View), в Поток (Stream). Другие члены команды будут выполнять Обновление (Rebase) их Потока и забирать изменения, которые доставлены в родительский Поток.

ClearCase есть такое понятие как Динамическое представление (Dynamic View), это рабочее пространство, которое обновляется без вмешательства пользователя, на основе пользовательских настроек. ClearCase есть также концепция Статических представлений (Snapshot View), которое является копией рабочего пространства, ассоциированного с состоянием репозитория в определенный момент времени. Статическое представление приводится к «текущему состоянию»с помощью операции Обновить (Updating) представление. В любом из этих типов представлений, Базовые линии и Наборы изменений могут быть доставлены из потока в поток, при этом любые необходимые операции Слияния по отдельным файлам будут обнаружены системой, а затем их должен будет разрешить пользователь. Также как Компоненты получают Наборы изменений, применяемые к ним, отдельные Компоненты могут иметь Базовые линии (в основном как метка для всех артефактов в рамках Компонента или VOB), применяемые к ним. «Основная базовая линия» с набором базовых линий нескольких Компонентов называется Композитная базовая линия (Composite Baseline).

В RTC SCM есть многие из этих же понятий, но есть некоторые незначительные отличия. Jazz имеет единое хранилище, в котором хранятся его артефакты как REST ресурсы. Эти ресурсы хранятся в базе данных. Jazz поддерживает использование многих баз данных, включая Oracle, DB2 и SQL Server. Это, в общем, используется как Jazz Репозиторий (Jazz Repository). В Jazz разрабатываемая программа разбивается на программные Компоненты (Component). Эти Компоненты могут содержать артефакты в любой структуре каталогов, и параллельная разработка поддерживается с использованием Jazz Потоков (Jazz Streams). Пользователи, работающие с Jazz Компонентой, присоединяются к проекту и создают своё собственное Рабочее пространство Репозитория (Repository Workspace) (которое содержит копии всех их Наборов изменений (Change Set)), а также Личное Рабочее пространство (Sandbox) на своем локальном компьютере. Все изменения файлов отслеживаются клиентом Jazz, и пользователь в дальнейшем будет Регистрировать (Check In) свои изменения. В Jazz нет понятия изъять на редактирование, но Jazz поддерживает Блокировку (Locking) ресурсов. Когда пользователь видит изменения в своем Личном рабочем пространстве, он будет Регистрировать изменения и связывать их с Набором изменений, который собирает отдельные изменения и сохраняет их в Рабочем пространстве Репозитория. Эти Наборы изменений могут быть Доставлены (Deliver) в один или несколько Потоков Jazz. Другие члены команды будут Принимать (Accept) изменения в свои Рабочие пространства Репозитория из этого потока, и поставлять сделанные изменения на Родительский поток.

Личное рабочее пространство пользователя или Рабочее пространство Eclipse (Eclipse Workspace), может иметь свой проверяемый в любое время статус, с помощью интерфейса указывающего на все потенциальные исходящие Наборы изменений (работу, которую пользователь хочет Доставить), а также входящие Наборы изменений (работа, которая выполнена другими членами команды). Пользователи имеют возможность выбрать Наборы изменений либо для Доставки (Наборы изменений становятся доступными для всех членов команды), либо для Принятия (применение Наборов изменений в Поток в свои Рабочие пространства Репозитория и Личное) на индивидуальной основе. Базовые линии (Baselines) для Компонентов также можно создавать, и набор Базовых линий для нескольких Компонентов называется Снимком (Snapshot). Его не следует путать со Статическим представлением в ClearCase, т.к. эти понятия совершенно различны.

Есть ряд тонких различий в том, как системы работают, и это отражается на механизмах взаимодействия пользователей с этими системами. В ClearCase пользователи часто создают Потоки и Ветви для изолирования своей работы. Часто пользователи создают несколько Представлений (рабочих пространств), и один набор изменений выполняется в своем Представлении. С помощью этого изменения могут быть изолированы друг от друга, и обеспечивается отсутствие зависимостей артефактов создаваемых между Наборами изменений. В Jazz пользователь выполняет одно изменение в одно время, в рамках своего Локального рабочего пространства. Пользователи, работающие с несколькими изменениями, имеют выбор, они могут либо создать несколько Локальных рабочих пространств и Рабочих пространств Репозитория или они могут Приостановить (Suspend) работу над одним Набором изменений прежде чем приступить к другим. Возможность Приостановить работу по существу принимает все изменения, связанные с Набором изменений, и сохраняет их в Репозитории, после этого пользователь может Возобновить (Resume) (или вернуться) к этим изменениям в дальнейшем. Рабочее пространство при этом возвращается в состояние, в котором оно находилось, когда был применен предыдущий Набор изменений. Это помогает сократить количество Рабочих пространств, которые разработчику нужно поддерживать.

При использовании ClearCase с ClearQuest и UCM можно связывать с Запись ClearQuest (ClearQuest Record) с Набором изменений. Это требует некоторой настройки и доступности Репозитория ClearCase (VOB) и базы данных CQ. В Jazz/RTC вся эта информация находится в том же хранилище, тут связь создается между Рабочими элементами (Work Item) и Набором изменений. Так как все это построено на основе REST, различные типы объектов Jazz могут быть связаны друг с другом, обеспечивая большую гибкость в связях между артефактами разработки.

Понятие ClearCase Эквивалент Jazz Описание
Check Out/Check In Check In Регистрация изменений в Репозиторий
Activity Change Set Собирает набор изменений файлов в один пакет изменений, обычно связанных с Записью CQ/Рабочим элементом
VOB Jazz Repository Хранит данные в системе управления версиями – один Jazz Репозиторий, несколько VOB-ов
Dynamic View n/a Виртуальное рабочее пространство, содержание которого является динамическим
View Storage Repository Workspace Это не очень хорошее сравнение для Рабочего пространства Репозитория, но хранилище представления на сервере представлений приблизительно похоже
Snapshot View Sandbox/Eclipse Workspace Рабочее пространство, основанное на копировании, используется для разработки
Updating Synchronizing/Accept Обновление рабочего пространства пользователя, когда изменения от других членов команды загружаются в личное рабочее пространство пользователя
Deliver Deliver Продвижение набора изменений из рабочей области в поток, где они становятся общими для всей команды
Rebase Accept Изменения, выполненные другими членами команды, загружаются в личный рабочий поток пользователя
Reserved Check Out Locked Возможность «зарезервировать» ресурс, вы будете являться единственным пользователем, который может изменить ресурс
Baseline Baseline Набор файлов (конфигурация) в рамках компонента в определенный момент времени
Composite Baseline Snapshot Набор различных компонентов, а также конкретная базовая линия в этих компонентах
UCM Process Templates (как Scrum) Стандартно поставляемый процесс, который определяет типы записей/рабочих элементов, связи и процессы, связанные с ними
Stream/Branch Stream Логическое «разделение» кода, обеспечивающее параллельную разработку и изоляцию
Merge Merge Взятие версий одного и того же файла в двух различных ветвях и сопоставление изменений, внесенных в эти файлы
n/a Suspend/Resume Возможность временного хранения или восстановления изменений, сделанных в рабочем пространстве, чтобы вернуть рабочее пространство в некоторую известную конфигурацию

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

Об авторе

Daniel Toczala является Техническим лидером команды Jazz Jumpstart. Он работал в прошлом с Rational Services в качестве Senior Solutions Architect. Он использовал свой опыт в оказании помощи различным клиентам в осуществлении организационных изменений, чтобы помочь построить концепции шаблонов развертывания. Он сделал многочисленные презентации о том, как организации могут использовать технологий Jazz и Agile подходы в разработке программного обеспечения для повышения качественного результата, который организации по разработке ПО поставляют своим клиентам.

Dan путешествует по миру, помогая клиентам IBM, но его дом в Нью-Хартфорд, штат Нью-Йорк. С ним можно связаться по dtoczala@us.ibm.com.

Реклама

комментариев 11 to “Сравнение концепции ClearCase UCM и RTC”

  1. Aquary said

    Спасибо, интересно было взглянуть на RTC в сравнении.

    Вопрос. Перевод термина Baseline как «Базовая линия» — это ваш вариант или это рекомендованый перевод от самих IBM Rational?

    Просто в своих публикациях я перевел его как «Базовая конфигурация» или «Базис». На мой взгляд, «линия» русскому читателю никаких зацепок читателю не дает, тогда как в английском line имеет местами более широкое значение, например «черта», иногда «итог». Т.е. baselining — это подведение итога, содание базиса, отправной точки.
    Отсюда и вопрос.

    • Это стандартный вариант, который используется в практике, в том числе Rational и ГОСТ 12207. В русском варианте RUP используется такое понятие как «контрольная версия».

      • Aquary said

        Ясно, спасибо. Ещё тогда вопрос по терминологии — что понимается под словом «конфигурация» в этих же источниках?

        • ГОСТ (ISO 12207) на эту тему говорит так:
          — базовая линия (baseline): Официально принятая версия элемента конфигурации, независимая от среды, формально обозначенная и зафиксированная в конкретный момент времени жизненного цикла элемента конфигурации.
          — элемент конфигурации (configuration item): Объект внутри конфигурации, который удовлетворяет функции конечного использования и может быть однозначно определен в дан-ной эталонной точке.

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

  2. Добавлю свое полное согласие 🙂
    Только есть одно маленькое «но»… базовая версия в ГОСТе и бейзлайн в рупе — это несколько не одно и тоже.
    Хотелось бы иметь красивый литературный перевод от вендора, но его нет, не было, и, видимо, не будет…
    Предлагаю самим подобрать правильные термины и пропагандировать всеми возможными методами, ибо многообразие синонимов не всегда служит добрую службу, особенно при объяснении чего-то нового слушателям\студентам и тд.

    • Aquary said

      Скромно предложу свою терминологию… 🙂
      У меня иерархия получается следующая
      В проекте есть рабочие продукты, под контролем SCM они считаются элементами конфигурации.

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

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

      Базовая конфигурация (baseline) — конфигурация (см. пред.), которая считается достаточно стабильной для того, чтобы быть основой для дальнейшей работы или быть отгруженной заказчику. Т.е. это тоже срез, только «заапрувленный».

      Как-то так.

      • Приблизительный перевод CMMI 1.3, который смотрит немного шире 🙂

        Базовая линия – набор спецификаций или артефактов, которые должны быть формально проверены и утверждены, что представляется как базис для дальнейшей разработки и может быть изменен только через процедуры управления изменениями.

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

        Элемент конфигурации – множество артефактов, которое предназначено для управления конфигурацией и рассматривается как единое целое в процессе управления конфигурацией.

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

        • Aquary said

          Осталось узнать, как CMMI трактует термины «версия» и «конфигурация».

          Кстати, «множество артефактов, которое предназначено для управления конфигурацией»… читает так, как будто артефакты управляют конфигурацией… и не управление конфигурацией (собственно SCM) управляет этими самыми артефактами 🙂

          • а там нет в глоссарии версия и конфигурация 🙂

            • Aquary said

              Стало быть, такая KPA как «Configuration management» там есть, но что такое configuration — неизвестно… 🙂
              Что интересно — я ведь сам в своё время сам участвовал в подготовке к асесменту на 4 уровень CMMI, доки писал по СМу… и ни у кого даже вопроса не возникло — что же означает это самый configuration, которым управляют. 🙂

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: