Управление версиями и выпусками

Управление версиями и выпусками ПО необходимо для идентификации и слежения за всеми версиями и выпусками системы. Менеджеры, отвечающие за управление версиями и выпусками ПО, разрабатывают процедуры поиска нужных версий системы и следят затем, чтобы изменения не осуществлялись произвольно. Они также работают с заказчиками и планируют время выпуска следующих версий системы. Над новыми версиями системы должна работать команда по управлению конфигурацией, а не разработчики, даже если новые версии предназначены только для внутреннего использования. Только в том случае, если информация об изменениях в версиях вносится исключительно командой по управлению конфигурацией, можно гарантировать согласованность версий.

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

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

В настоящее время для поддержки управления версиями разработано много разнообразных CASE-средств. С помощью этих средств осуществляется управление хранением каждой версии и контроль за допуском к компонентам системы. Компоненты могут извлекаться из системы для внесения в них изменений. После введения в систему измененных компонентов получается новая версия, для которой с помощью системы управления версиями создается новое имя.

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

1. Нумерация версий. Каждый компонент имеет уникальный и явный номер версии. Эта схема идентификации используется наиболее широко.

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

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

Нумерация версий. По самой простой схеме нумерации версий к имени компонента или системы добавляется номер версии. Например, Solaris 2.6 обозначает версию 2.6 системы Solaris. Первая версия обычно обозначается 1.0, последующими версиями будут 1.1, 1.2 и т.д. На каком-то этапе создается новая выходная версия – версия 2.0, нумерация этой версии начинается заново – 2.1, 2.2 и т.д. Эта линейная схема нумерации основана на предположении о последовательности создания версий. Подобный подход к идентификации версий поддерживается многими программными средствами управления версиями, например RCS.

На рис. 20.2 графически проиллюстрирован описанный способ нумерации версий. Стрелки на рисунке проведены от исходной версии к новой, которая создается на ее основе. Отметим, что последовательность версий не обязательно линейная – версии с последовательными номерами могут создаваться на основе разных базовых версий. Например, на рис. 20.2 видно, что версия 2.2 создана на основе версии 1.2, а не версии 2.1. В принципе каждая существующая версия может служить основой для создания новой версии системы.

Рисунок 20.2. Структура системных версий.

 

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

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

- заказчик;

- язык программирования;

- состояние разработки;

- аппаратная платформа;

- дата создания.

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

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

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

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

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

Управление выходными версиями. Выходной версией системы называется версия, поставляемая заказчику. Менеджеры по выпуску выходных версий отвечают за решение о дате выпуска, за управление процессом создания выходной версии, а также за создание документации.

Выходная версия системы включает в себя не только системный код, но также ряд компонентов.

1. Конфигурационные файлы, определяющие способ конфигурирования системы для каждой инсталляции.

2. Файлы данных, необходимые для работы системы.

3. Программа установки, которая помогает инсталлировать систему.

4. Документация в электронном и печатном виде, описывающая систему.

5. Упаковка и рекламные материалы, разработанные специально для этой версии системы.

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

1. Версия 1 системы находится в эксплуатации.

2. Выпускается версия 2, требующая установки новых файлов данных. Однако некоторые пользователи не нуждаются в дополнительных возможностях версии 2 и продолжают использовать версию 1.

3. Версия 3 требует файлов, содержащихся в версии 2, но сама не содержит этих файлов.

Дистрибьютор ПО не может знать наверняка, что файлы данных, требующиеся для версии 3, уже установлены; некоторые пользователи будут переходить от версии 1 к версии 3, минуя версию 2. У других пользователей вследствие каких-либо обстоятельств файлы данных, связанные с версией 2, могут быть изменены. Отсюда следует простой вывод: версия 3 должна содержать все файлы данных.

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

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

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

 

 

Таблица 20.1. Факторы, влияющие на стратегию выпуска версий системы

Фактор	Описание
Техническое качество системы	Необходимость выпуска новой версии обусловлена зарегистрированными ошибками в существующей версии системы. Небольшие дефекты можно устранить с помощью заплат (patches), которые часто распространяются через Internet
Пятый закон Лемана	Этот закон постулирует постоянство приращения функциональных возможностей в каждой выходной версии по сравнению с предыдущей. Однако существуют и исключения, например за версией с достаточно большими изменениями следует версия с исправлением ошибок
Конкуренция	Необходимость новой версии объясняется наличием на рынке конкурирующих продуктов
Требования рынка	Отдел маркетинга компании может приурочить выход новой версии к определенной дате
Предложения заказчика об изменениях в системе	Для разработанных под заказ систем заказчик может предложить внести в систему ряд изменений, тогда новая версия выйдет сразу после реализации этих изменений

 

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

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

 

Сборка системы

Сборкой системы называют процесс компиляции и связывания программных компонентов в единую исполняемую программу. Перед сборкой системы полезно ответить на следующие вопросы.

1. Все ли компоненты, составляющие систему, включены в инструкцию по сборке?

2. Каковы версии компонента, перечисленные в инструкции по сборке?

3. Доступны ли все необходимые файлы данных?

4. Если на файлы данных используются ссылки внутри компонентов, то каковы имена этих файлов в выходной версии?

5. Доступны ли нужные версии компилятора и других необходимых средств? Действующие версии программных средств могут быть несовместимы с более старыми версиями, которые применялись при разработке системы.

В настоящее время существует много средств управления конфигурацией, автоматизирующих процесс сборки системы. Команда управления конфигурацией пишет сценарий, в котором определены зависимости между различными компонентами системы. В нем также указаны средства компилирования и связывания компонентов системы. Средства компоновки интерпретируют сценарий сборки системы и вызывают программы, необходимые для сборки исполняемой системы. Процесс сборки системы представлен на рис. 20.3.

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

 

 

Рисунок 20.3. Сборка системы.

 

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