Этот обзор посвящён 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).