Окончание. Начало см. PC Week/RE, № 8/97, с. 43
ОСНОВНЫЕ ДЕЙСТВИЯ В SCM
Основные действия в конфигурационном управлении связаны с хранением изменяемых объектов (см. "Архивы версий") и регистрацией процедуры внесения изменения (см. "Трекинг проблем"). Также очень важны процессы группирования объектов. Причем эти процессы могут происходить как при образовании новых объектов (см. "Комплексирование"), так и при внесении изменений в группы (см. "Проект"). Но перед тем, как манипулировать объектами, необходимо их перечислить, т. е. идентифицировать.
Идентификация. Начав что-то контролировать, необходимо знать, а что именно мы контролируем. Процедуры идентификации обычно включают в себя способ выделения контролируемой системы из неконтролируемого внешнего окружения, которое не является объектом изменений.
Выделив систему, необходимо выбрать способ классификации объектов. Обычно это проделывают одновременно с введением правил наименования объектов.
Идентификация должна быть воспроизводимой, например, состав файлов исходных текстов должен определяться проектным решением на уровне построения моделей системы.
Следствием идентификации является спецификация состава системы, т. е. документ, перечисляющий и определяющий объекты конфигурационного управления.
Архивы версий. Ничего не выбрасывать! Вот принцип осторожного человека. Ведь намного хуже выбросить то, что потом может понадобиться, чем хранить ненужное. Версионное хранение основано именно на таком принципе.
На рис. 1 изображены файлы (foo.c, foobar.exe и др.), рядом с ними расположены соответствующие им версионные деревья. На некоторых ветвях могут находиться метки, чтобы обозначить определенные вехи. (На рисунке видно, что последние версии файлов заблокированы программистом, - значит, развитие системы продолжается.)
Наглядна группировка файлов. В проекте FooBar есть набор Code, содержащий объекты изменений, вносимых программистом. Набор Deliverables содержит непосредственно поставляемые файлы. Один и тот же объект (например, readme.txt) может находиться в нескольких наборах (допустим, в Dox и Deliverables).
На рис. 1 показано, как осуществляется версионное хранение изменяемого файла. Этому файлу соответствует архив, содержащий в себе дерево версий. В архиве находятся все версии, и любая из них может быть оттуда получена. Как это сделать - это уже другая проблема (см. "Три поколения средств версионного хранения"), скажем, можно разложить версии в разные каталоги .
Люди, занимающиеся конфигурационным управлением, как правило, осторожны, поэтому обычно они спрашивают: "А не расходуется ли таким образом место зря?". Вот это уже зависит от реализации архива. Большинство систем версионного хранения, и PVCS в том числе, хранят только изменения базовой версии. Это позволяет хранить многие типы файлов (например, исходные тексты), почти не расходуя зря дисковое пространство.
Как показано на рис. 1, версии помечаются цифрами, например "1.1". Обычно эти цифры означают номер "ревизии" и "модификации". Можно также помечать версию файла и произвольной строкой (меткой). Это особенно удобно при группировании файлов.
Рис. 1. Дерево версий PVCS Version Manager
Трекинг проблем. Лишь изменения кода при кодировании не рассматриваются как объект трекинга. Во всех других случаях изменения необходимо прослеживать. Заметим, что изменение, которое еще не стало изменением, называется запросом на изменение (Software Change Request).
Прослеживание (трекинг) изменений - это фиксация следующей информации.
Почему был сформирован запрос на изменение?
Кем и когда он был сформирован?
Кто и когда его рассматривал?
Какие решения были приняты?
В какие файлы были внесены изменения?
Как проверялось (верифицировалось) данное изменение?
Каков окончательный статус запроса на изменение?
Такого рода информация может храниться в специализированной базе данных слежения. Например, на рис. 2 в окне Query показана БД слежения PVCS Tracker.
Рис. 2. База данных слежения PVCS Tracker
Эта БД может быть уподоблена картотеке: в верхней части окна Query мы видим верхние срезы карточек, а в нижней - содержимое текущей карточки. Карточки (запросы на изменение) могут вноситься разными членами группы (поле Submitter), и в процессе работы могут адресоваться разным членам группы (Owner). Текущая карточка была создана проектировщиком (Devo) и адресована кодировщику (Coder). После исполнения задания она была переадресована тестировщику (Tester), и после тестирования закрыта. Таким способом назначаются задания членам группы.
На рисунке отображено полное содержимое базы данных, но в процессе работы каждый член группы видит только те запросы, которые касаются непосредственно его.
Для баз данных слежения характерна тесная интеграция с системами версионного хранения.
Комплексирование. Обычно под комплексированием (сборкой) подразумевают сборку исполняемого модуля из исходных. При комплексировании из нескольких объектов конфигурационного управления создаются новые.
Основное требование, которое предъявляется к процессу сборки - быть конфигурационно определенным. Это означает, что составляющие объекты (компоненты) должны иметь определенную версию, либо версии компонентов должны быть согласованы между собой. Результат сборки должен быть идентифицирован самим процессом сборки. Этим комплексирование отличается от идентификации.
Проекты и группирование объектов SCM. Группирование объектов - это еще и выделение групп объектов, представляющих собой в определенном смысле объект изменения. Яркий пример такого рода - проект в целом. Объекты изменения, составляющие проект, должны быть совместно изменены, только тогда проект будет успешно завершен.
Группирование файлов по совместности изменений тесно связано со сборкой. Именно файлы, которые будут впоследствии собраны в единый объект, должны образовывать групповой объект изменения. В PVCS группирование файлов в объект изменения осуществляется с помощью метаданных, связывающих файлы - объекты конфигурационного изменения - в проект, причем внутри проекта возможно выделять также групповые объекты изменения меньшего ранга (см. рис. 1). К сожалению, PVCS VM не поддерживает отображение проектного группирования в процедуры сборки PVCS Configuration Builder. Впрочем, его не поддерживает ни одно из основных средств конфигурационного управления.
Продвинутое конфигурационное управление
Есть действия, не связанные исключительно с манипуляциями объектами и их изменениями. Часто они связаны с поддержкой интеграции конфигурационного управления с другими действиями при разработке.
Трекинг требований. Трекинг требований - это технология прослеживания причинно-следственной зависимости объектов конфигурационного управления в масштабах полного жизненного цикла. Она служит для определения области распространения изменения (области влияния или зависимости) при изменении единственного требования. Проблема тут связана с тем, что зависимость необходимо установить между разнородными объектами конфигурационного управления (например, между моделями и исходным текстом), и часто полноценная трассировка требует выделять в качестве области влияния (зависимости) части файлов [см. "Хранение версий частей файлов (субфайловое версионное хранение)"].
Трекинг требований может быть осуществлен при совместном управлении объектами конфигурационного управления на всех этапах жизненного цикла. В комплексе средств PVCS есть средство PVCS Requisite Pro, служащее для реализации трекинга требований.
Метрики и управление проектом. Управление проектом - это разделение проекта (задачи в целом) на подзадачи, определение их трудоемкости, распределение между исполнителями и контроль за исполнением.
Очевидно, что SCM как система контроля изменений может быть использована для управления проектом. Для этого необходимы поддержка метрической характеристики изменений, средства связывания объектов SCM с подзадачами управления проекта и передачи показателей метрик трудоемкости опять в системы управления проектами. Эта задача пока не реализована большинством средств SCM.
Для распределения заданий между участниками проекта (см. рис. 2) можно применить средства прослеживания (Tracking). Такой способ не учитывает трудоемкости заданий и не интегрирован с системами управления проектом, но его можно реально использовать уже сейчас с помощью современных систем трекинга.
Тестирование и прослеживание проблем. Большинство прослеживаемых запросов на изменения, нуждающихся в трекинге, - это запросы на исправление ошибки, поэтому трекинг проблем имеет тесную связь с тестированием и контролем качества.
Благодаря регистрации и хранению информации об ошибках можно легко получить сводную информацию об ошибках и их исправлениях в программной системе, в том числе статистику ошибок и их исправлений, распределение ошибок по разработчикам и модулям, временны/е характеристики процесса устранения ошибок и обнаружения новых. Вся эта информация имеет ключевое значение для процесса тестирования, и соответствующие возможности поддерживаются большинством современных средств трекинга проблем.
Хранение версий частей файлов (субфайловое версионное хранение). Обычно объектом конфигурационного управления считается файл. Однако в ряде случаев, например в больших программных системах на объектно-ориентированных языках, единицей хранения может быть выбран класс или даже его составляющие.
Другой пример субфайлового изменения - это документ в формате WinWord, в котором информация в разделах может быть вполне независимой, и поэтому должна рассматриваться как независимые объекты изменения. Именно такой механизм и используется при трекинге требований, записанных в документе формата WinWord.
Полноценное использование субфайлового версионного хранения требует построения репозитория (см. "Репозиторий проекта"), в котором механизм хранения реализован на логическом уровне, соответствующем выбору объектов хранения.
Ярким примером субфайлового версионного хранения является система HOPE (Human Oriented Programming Environment). В этой системе, ориентированной на работу только с объектно-ориентированными языками Си++ и Java, в репозитории проекта хранятся не версии файлов, а версии более мелких объектов, называемые "частицами" (particles).
Распределенная SCM. Весьма типична ситуация, когда разработка ведется в разных географических точках. Поскольку при этом невозможно вести единый версионный архив, возникает необходимость использовать распределенные версионные архивы.
Эти архивы очень напоминают распределенные базы данных. В частности, внесение изменений в распределенные архивы может быть осуществлено двумя основными способами:
путем одновременного внесения изменений во все архивы ("двухфазный COMMIT" в терминах распределенных БД);
путем внесения изменения в один архив с последующей синхронизацией ("отложенная транзакция" в терминах распределенных БД).
Классическим примером системы, поддерживающей распределенное конфигурационное управление, служит ClearCase с его ClearCase Multisyte. Эта система позволяет использовать множественные базы версионных объектов (VOB - versioned objects base), тогда как PVCS SiteSync поддерживает механизм отложенной синхронизации.
ТЕНДЕНЦИИ РАЗВИТИЯ СРЕДСТВ КОНФИГУРАЦИОННОГО УПРАВЛЕНИЯ.
Развитие средств конфигурационного управления связано с развитием средств разработки ПО - способами предоставления разработчику доступа к версионным архивам, интеграцией с данными проекта в целом и связью со средствами разработки.
Три поколения средств версионного хранения. Выделяют следующие поколения средств версионного хранения:
- файловое версионное хранение;
- проектно-ориентированное версионное хранение;
- виртуальная файловая система.
PVCS VersionManager осуществляет проектно-ориентированное хранение на базе файл-ориентированного. Некоторые средства, реализующие только проектно-ориентированное хранение, затрудняют совместное использование компонентов (и архивов), которое на уровне файл-ориентированного хранения выполняется элементарно.
Виртуальная файловая система обеспечивает высокую степень интеграции со средствами разработки (по стандартным интерфейсам файловых функций), но ее переносимость сильно затруднена.
Наилучшим вариантом я бы счел виртуальную файловую систему с возможностью независимого доступа как к проектам, так и к файлам.
Репозиторий проекта. Современные средства разработки, особенно сложных клиент-серверных систем, часто размещают данные проекта в репозитории - специальной базе данных, логически приспособленной для хранения данных проекта.
Соответственно, и данные конфигурационного управления должны храниться в репозитории, т. е. репозиторию должны быть приданы свойства версионного архива.
Современные средства трекинга проблем способны размещать свои данные в репозиториях, в частности, PVCS Tracker способен хранить данные слежения в ODBC-совместимой базе данных.
Модульность и интерфейсы. Первоначально проблема модульности средств SCM и интерфейсов связи между этими модулями возникла в связи с необходимостью интеграции средств версионного хранения со средствами разработки.
С PVCS VersionManager интегрировано наибольшее число средств разработки. Эта интеграция осуществляется как по интерфейсу вызова командной строки, так и с помощью API самого VersionManager.
Другой распространенный интерфейс - это SCC фирмы Microsoft. Он был первоначально разработан как интерфейс связи SourceSafe со средствами разработки одноименной фирмы и впоследствии предложен разработчикам средств SCM в качестве стандартного интерфейса. Сейчас этот интерфейс поддерживается основными производителями средств SCM.
Приложение. Сводка возможностей основных средств SCM
В таблице приведен список средств конфигурационного управления, подобранный с учетом следующих особенностей средств SCM:
- реализации на широком спектре платформ, включая PC;
- поддержки разработки клиент-серверных систем;
- широкого набора стандартных функций, наличия интегрированных с системой средств контроля версий (VM), трекера (PT), систем управления проектом (PM), сборщиков (CB), средств управления проектом (PM) и прослеживания требований (RT);
- наличия уникальных функциональных возможностей.
Также в таблице учитывались следующие особенности:
- наличие API, в особенности интерфейса SCC, открытость версионных архивов;
- модель хранения (способ хранения версионных данных);
- модель доступа (объекты версионного хранения);
- типы хранимых данных;
- наличие средств работы в географически распределенной среде.
Приведенные в таблице данные позволяют сделать ряд выводов.
В практике разработки информационных систем стала общепринятой интеграция средств версионного хранения инструментов и трекинга проблем. Также весьма популярно включение в инструментарий средств управления проектом (ACVS, Continuus/CM, PCMS, HOPE). Есть отдельные примеры реализации трекинга требований (AllChange, PVCS).
Большинство средств поддерживает стандартный интерфейс доступа к версионному контролю.
Версионные архивы хранятся как в файлах архивов, так и (в клиент-серверных системах) в репозиториях. Доступ к версиям объектов осуществляется, за редким исключением (ACVS, HOPE), на уровне файлов.
Растет число средств, поддерживающих распределенную разработку (ClearCase, CVS, PVCS SiteSync) либо внешний доступ по IP (Perforce, SoftBench CM, VCS).
С автором статьи можно связаться по телефону: (095) 217-2556 и адресу: george@arguss.msk.su. .
Георгий Серяков
В будущем инструментарии разработчика будут интегрированы средства SCM, автоматизации разработки и единый репозиторий
СРЕДСТВА КОНФИГУРАЦИОННОГО УПРАВЛЕНИЯ
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|Название |URL |Платформы |Функциональност|Открытость |Модель |Модель |Хранимые |Распределенная |
| | | | | |хранения |доступа |данные |разработка |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|ACVS |www.arstpa.com/acvs.html |Сервер: Unix |PT, PM, RT | |Репозиторий | | | |
| | |Клиент: | | | | | | |
| | |Windows | | | | | | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|TRUEchange |www.truesoft.com/ |Win, Unix |VM, PT |SCC |Объектный |Oracle |Исходные |PPP |
|(ADC/Pro) | | | | |репозиторий | |тексты, | |
| | | | | | | |двоичные | |
| | | | | | | |данные | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|CCC/Harvest |www.platinum.com |Сервер: Unix |VM |API | |Набор | | |
| | |Клиент: | | | |изменений | | |
| | |UnixWin | | | |(Change | | |
| | | | | | |set) | | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|ClearCase |www.pureatria.com |Сервер: |VM, CB, PM, RT |SCC |Виртуальная |Файл |Файл |Multisite |
| | |Unix, NT | | |файловая | | | |
| | |Клиент: | | |система | | | |
| | |Windows | | | | | | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|Continuus/CM |www.continuus.com |Win, Unix |PM, VM, PT, CB |SCC |Репозиторий |Файл |Исходные | |
| | | | | |кода | |тексты | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|CVS |www.cyclic.com |Unix, VMS, |VM | |Архив |Модули | |CVS protocol |
| | |NT, OS/2 | | | | | | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|HOPE |www.aks.com/hope/hope.htm|Win, NT |VM, CB, PM | |Репозиторий |Particle |Файл | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|IBM TeamConnection | | |VM, PT, CB | |Объектно-ори|Объект |Си, Си++, | |
| | | | | |ентированный| |Java Объект | |
| | | | | |репозиторий | | | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|MKS RCS |www.mks.com |DOS, Win, |VM, PT |SCC | |Исходные | | |
| | |Unix | | | |тексты | | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|Perforce (P3) |www.perforce.com |Win, Unix |VM | |Репозиторий | |Файл | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|PVCS |www.intersolv.com |Win, Unix |VM, PT, CB |API |Архив |Файл |Файл |PVCS SiteSync |
| | | | | | | | |(Gateway) |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|Razor |www.tower.com |Unix, Win |VM, PT | | | | | |
| | |(client) | | | | | | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|RCE |www.xcc-ka.de |Win, Unix |VM |API |Архив |Файл |Файл | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|SoftBench CM |hpcc998.external.hp.com: |Unix |VM | |Архив | |Файл |IP |
|Product |80/sesd/products/softcm/ |(сервер) + | | | | | | |
| |main.html |Win (клиент) | | | | | | |
| | | | | | | | | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|Tesseract |lia.co.za/pub/tesseract/ |Win |VM | | | |Файл |IP |
| |tsrhome.htm | | | | | | | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|VCS | |Win, Unix |VM, PT, CB | |Архив |Файл |Файл | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
|Visual SourceSafe |www.microsoft.com/ssafe/ |Win |VM |SCC | | | | |
+--------------------+-------------------------+-------------+---------------+-------------+------------+-----------+--------------+---------------+
