Идентификация на основе изменений

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

Идентификация на основе изменений применяется скорее к системам, чем к систем­ным компонентам; версии отдельных компонентов скрыты от пользователей системы управления конфигурацией. Каждое изменение в системе описывается массивом изменений, где указаны изменения в отдельных компонентах, реализующие данное системное изме­нение. Массивы изменений могут применяться последовательно таким образом, чтобы создать версию системы, в которой реализованы все необходимые изменения. В этом слу­чае не требуется точного обозначения версии. Команда управления конфигурацией рабо­тает с системой управления версиями посредством системы управления изменениями.

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

Средства поддержки управления изменениями

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

Поэтому для поддержки процесса управления изменениями достаточно следующих средств:

1. Редактор форм, позволяющий создавать и заполнять формы запросов на изменения.

2. Система автоматизации документооборота, которая позволяет фиксировать закреп­ление обработки форм запросов на изменения за членами команды по управлению конфигурацией и определяет порядок этой обработки. Эта система может также автоматизировать процесс передачи заполненных форм "нужным людям в нужное время" и информировать о состоянии процесса внесения изменений. Как правило, эта система использует электронную почту для пересылки сообщений.

3. База данных изменений, которая используется для хранения всех предложенных из­менений и может быть связана с системой управления версиями.

Средства поддержки управления версиями

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

Системы управления версиями могут отличаться друг от друга, но все они имеют базо­вый набор средств.

1. Средство идентификации версий. Системы управления версиями могут поддерживать различные подходы к идентификации версий.

2. Средство регистрации изменений. Регистрирует все изменения, сделанные в коде сис­темных компонентов. В некоторых системах управления версиями это средство используется для поиска нужной версии системы.

3. Средство поддержки параллельной разработки. Различные версии системы могут разра­батываться параллельно и изменяться независимо друг от друга. Система управле­ния версиями должна отслеживать компоненты, которые изменяются, и контроли­ровать, чтобы на один и тот же компонент не накладывались изменения, сделанные разными группами разработчиков. Некоторые системы позволяют единовременно изменять только один экземпляр компонента, другие автоматически разрешают возникшие коллизии, когда измененные компоненты возвращаются в систему управления версиями.

Некоторые системы сборки используют дату изменения файла как ключевой атрибут, определяющий, требуется или нет перекомпиляция. Если дата изменения файла исходно­го кода более поздняя, чем дата изменения соответствующего файла объектного кода, то этот объектный код необходимо создать заново. Это гарантирует, что вторичный объект будет создан на основе самой последней версии исходного кода. Если перекомпилируется ранняя версия исходного кода, то изменяется дата ее модификации и система сборки по этой дате определяет, какие компоненты должны быть перекомпилированы или созданы заново. Другие системы сборки используют более сложные подходы к управлению вто­ричными объектами. Они вводят дополнительный атрибут для вторичных объектов, где указывается версия исходного кода, на основе которого создан этот объект, и по возмож­ности сохраняются все версии вторичных объектов. Это позволяет иметь объектный код всех версий исходного кода без дополнительной перекомпиляции.

Наиболее известные системы контроля версий: Concurrent Versions System (CVS), Subversion (SVN), Microsoft Visual SourceSafe (VSS), Rational ClearCase.

Крупнейшие IT-компании

Microsoft