СТАТЬЯ
05.11.01

Rational UCM (Unified Change Management)

Этот обзор посвящён UCM (Unified Change Management) – унифицированному управлению изменениями – методологии, созданной Rational Software на базе наиболее удачного опыта в реализации процессов решения задач различной трудоёмкости – от постановки требований до выпуска релиза и его дальнейшей эксплуатации. Наиболее очевидны преимущества в применении этого стандарта при интеграции продуктов Rational Software: Rational ClearCase и Rational ClearQuest , соответственно средств конфигурационного и версионного контроля и управления запросами на изменения. Использование UCM помогает предупредить “изобретение велосипеда” как администраторами, так и менеджерами проекта, при выборе политики разработки проекта. Политика, ведомая с использованием UCM, затрагивает все основные виды деятельности упомянутых групп, начиная от добавления разработчика в проект и, вплоть, до описания основных типов изменений, относящимся к определённым частям проекта. Характерной чертой этой методологии является возможность управления изменениями на уровне задач вместо отслеживания изменений в отдельных файлах, либо директориях (в ClearCase с одинаковой простотой ставится под контроль как отдельно взятый файл любого типа, так и целая директория, размеры которой отдельно не ограничиваются). То есть каждая задача, прежде всего, ассоциируется с набором проделанных или планируемых изменений. Тем самым, автоматизируя многие рутинные задачи, UCM позволяет сфокусировать своё внимание на задачах более высокого уровня. Что касается присоединения к проекту новых разработчиков – вопрос, напрямую связанный с масштабируемостью – методология позволяет им присоединяться к проекту, сразу включаясь в работу с ясно поставленной задачей, при этом ClearCase автоматически заполняет рабочее пространство разработчиков правильными версиями файлов и директорий. И всё это лишь самое броское в рассматриваемой методологии.

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

С точки зрения UCM повседневная работа любого разработчика, участвующего в проекте, складывается из нескольких довольно определённых событий, которым легко поставить в соответствие некоторые атрибуты, с целью отличить действия каждого из разработчиков и ассоциировать их с конкретными изменениями проекта. Прежде всего, разработчик присоединяет проект (Join a project), в котором ему предстоит работать по указанию или согласованию с лидером (менеджером) проекта. Затем он ассоциирует свою работу с некоторыми группами изменений, называемых действиями (activities). Например, исправление дефекта, записанного в системе управления запросами на изменения, является действием. ClearCase изолирует действие разработчика от остальных членов проекта до тех пор, пока разработчик не сдаст это действие во всеобщее рабочее пространство (deliver activity). Сданные действия затем компилируются и тестируются. В итоге менеджер проекта собирает сданные действия в релиз (или базовую линию - baseline). После серий тестов релиза и исправлений найденных в нём ошибок, менеджер проекта назначает данный релиз, как рекомендуемый. Периодически производится синхронизация собственного рабочего пространства с рабочим пространством других разработчиков, делающих вклад в данный релиз (rebase your work area). Синхронизация представляет собой работу с рекомендованным релизом, который достиг определённого уровня стабильности, и содержит наиболее новые версии элементов проекта. Каждое рабочее пространство состоит из вида, который даёт возможность разработчику изменять дерево версий исходных файлов, и потока – управляющего объекта ClearCase, который формирует и следит за действиями, которые вы создаёте и сдаёте. Процесс выполнения действия может быть различным, но всегда в нём выделяют несколько определённых стадий: установка вида разработчика на данное действие (set activity), взятие версии файла с целью редактирования (check out), постановка файла под контроль после внесения изменений (check in), проверка выполненной работы, и, конечно, сдача действия (deliver activity).

Давайте рассмотрим некоторые основные концепции, на которых строится “фундамент” UCM при работе с Rational ClearCase и Rational ClearQuest. Обычно, используя понятие проекта, мы ссылаемся на группу людей, работающую над одной задачей, но в терминах UCM под проектом понимается объект, который определяет набор политик разработки. Политика проекта определяет, каким образом разработчики получают доступ к исходным файлам и директориям (компонентам - components)и как они изменяют их. Для того чтобы описать и сформировать работу разработчика, которая происходит над компонентами, в проекте используются следующие объекты ClearCase: релиз (baseline), поток слияния (integration stream), поток разработки (development stream), действия (activities). Компонента формируется из файлов и директорий менеджером, и, обычно, из компоненты можно скомпилировать работоспособную единицу программы. Файлы и директории в компоненте называются элементами, а каждый изменённый и поставленный на учёт (checked-in) элемент называется версией. Менеджер формирует релиз (baseline) из одной версии каждого элемента компонента, получая, фактически, версию компонента. Стоит заметить, что элементы хранятся в VOB (versioned object base), а структура компонента и релиза хранится в PVOB (project versioned object base). Как говорилось выше, действие (activity), это объект ClearCase, который сопоставляется версии, созданной для завершения конкретной задачи, причём, масштабы действия устанавливаются менеджером проекта. Действие, как объект, включает в себя заголовок, который описывает задачу, массив изменений, определяющий все версии, созданные или изменённые разработчиком в процессе работы над задачей и идентификационный номер пользователя – создателя действия. Действие, это объект одного потока, и он не может быть перенесён из одного потока в другой. Выясним, что представляют собой потоки. Эти понятия близки виду (view), но есть существенные различия: разработчик использует виды для создания новой версии элемента в компоненте, поток же используется для ведения контроля над всеми созданными разработчиком версиями. То есть вид создаёт и поддерживает дерево каталогов одной версии одного файла в одном или более компонентах. С помощью вида разработчик может изменять исходные файлы, компилировать их для проверки, и т.д. Поток, это более долгоживущий объект ClearCase. Он является членом одного UCM проекта и механизмом для создания конфигураций. Поток точно определяет набор доступных разработчику в данный момент версий для просмотра, изменения или компиляции. На момент создания потока, его конфигурация совпадает с релизом (baseline), то есть, он представляет собой одну версию каждого элемента в компоненте. Но при создании новой версии элементов, разработчик назначает новым версиям одно или более действий. Получается, что конфигурация потока задаётся релизом (baseline) плюс одно или более действий. Потоки в UCM принято разделять на два вида: потоки разработки и потоки слияний (development streams and integration streams). Обычно, каждый проект включает в себя несколько потоков разработки, которые начинаются от одного рализа (baseline) и развиваются отдельно. Наоборот, поток слияний, всегда единственный в проекте, и служит для объединения работы команды разработчиков, закончивших свои потоки разработки.

В итоге получаем относительно простую схему работы команды. Разработчики проекта сдают действия из своих потоков разработки в единый поток слияния, из которого получается общий набор версий, используемый для компиляции в масштабах проекта и отладки конечного продукта. Сборка сданных действий в поток слияний и, затем, в релиз (baseline)– задача менеджеров проекта. В их задачу так же входит описание значительных изменений в наиболее стабильных релизах, которые они должны назначить рекомендуемыми. После этого разработчики должны сделать синхронизацию их рабочего пространства с рекомендованным релизом (baseline).

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

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

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


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