Управление версиями. Практическое занятие 15. Тема 15. Управление версиями и выпусками
 Скачать 0.77 Mb.
|
|
ТЕМА 15. Управление версиями и выпусками. Цель настоящей темы – описание процесса управления программным кодом и документацией модифицируемых программных систем. Прочитав эту тему, вы должны: знать о четырех основных процессах управления конфигурацией: планирование управления, управление изменениями, управление версиями и сборкой системы; иметь представление о применении CASE-средств для поддержки процесса управления конфигурацией. Содержание: Управление версиями и выпусками Сборка системы CASE-средства для управления конфигурацией 1. Управление версиями и выпусками. Управление версиями и выпусками ПО необходимо для идентификации и слежения за всеми версиями и выпусками системы. Менеджеры, отвечающие за управление версиями и выпусками ПО, разрабатывают процедуры поиска нужных версий системы и следят за тем, чтобы изменения не осуществлялись произвольно. Они также работают с заказчиками и планируют время выпуска следующих версий системы. Над новыми версиями системы должна работать команда по управлению конфигурацией, а не разработчики, даже если новые версии предназначены только для внутреннего использования. Только в том случае, если информация об изменениях в версиях вносится исключительно командой по управлению конфигурацией, можно гарантировать согласованность версий. Версией системы называют экземпляр системы, имеющий определенные отличия от других экземпляров этой же системы. Новые версии могут отличаться функциональными возможностями, эффективностью или исправлениями ошибок. Некоторые версии имеют одинаковую функциональность, однако разработаны под различные конфигурации аппаратного или программного обеспечения. Если отличия между версиями незначительны, они называются вариантами одной версии. Выходная версия (release) системы – это та версия, которая поставляется заказчику. В каждой выходной версии либо обязательно присутствуют новые функциональные возможности, либо она разработана под новую платформу. Количество версий обычно намного превышает количество выходных версий, поскольку версии создаются в основном для внутреннего пользования и не поставляются заказчику. В настоящее время для поддержки управления версиями разработано много разнообразных CASE средств. С помощью этих средств осуществляется управление хранением каждой версии и контроль за допуском к компонентам системы. Компоненты могут извлекаться из системы для внесения в них изменений. После введения в систему измененных компонентов получается новая версия, для которой с помощью системы управления версиями создается новое имя. 1.1. Идентификация версий. Любая большая программная система состоит из сотен компонентов, каждый из которых может иметь несколько версий. Процедуры управления версиями должны четко идентифицировать каждую версию компонента. Существует три основных способа идентификации версий. Нумерация версий. Каждый компонент имеет уникальный и явный номер версии. Эта схема идентификации используется наиболее широко. Идентификация, основанная на знамениях атрибутов. Каждый компонент идентифицируется именем, которое, однако, не является уникальным для разных версий, и набором значений атрибутов, разных для каждой версии компонента. Здесь версия компонента идентифицируется комбинацией имени и набора значений атрибутов. Идентификация на основе изменений. Каждая версия системы именуется так же, как в способе идентификации, основанном на значениях атрибутов, плюс ссылки на запросы на изменения, которые реализованы в данной версии системы. Таким образом, версия системы идентифицируется именем и теми изменениями, которые реализованы в системных компонентах. Нумерация версий По самой простой схеме нумерации версий к имени компонента или системы добавляется номер версии. Например, Solaris 2.6 обозначает версию 2.6 системы Solaris. Первая версия обычно обозначается 1.0, последующими версиями будут 1.1, 1.2 и т.д. На каком-то этапе создается новая выходная версия – версия 2.0, нумерация этой версии начинается заново – 2.1, 2.2 и т.д. Эта линейная схема нумерации основана на предположении о последовательности создания версий. Подобный подход к идентификации версий поддерживается многими программными средствами управления версиями, например RCS. На рис. 15.1 графически проиллюстрирован описанный способ нумерации версий. Стрелки на рисунке проведены от исходной версии к новой, которая создается на ее основе. Отметим, что последовательность версий не обязательно линейная – версии с последовательными номерами могут создаваться на основе разных базовых версий. Например, на рис. 15.1 видно, что версия 2.2 создана на основе версии 1.2, а не версии 2.1. В принципе каждая существующая версия может служить основой для создания новой версии системы.  Рис. 15.1. Структура системных версий Данная схема идентификации версий достаточно проста, однако она требует довольно большого количества информации для сопоставления версий, что позволяло бы отслеживать различия между версиями и связи между запросами на изменения и версиями. Поэтому поиск отдельной версии системы или компонента может быть достаточно трудным, особенно при отсутствии интеграции между базой данных конфигураций и системой хранения версий. Идентификация, основанная на значениях атрибутов Основная проблема схем явного именования версий заключается в том, что такие схемы не отображают тех признаков, которые можно использовать для идентификации версий, например: заказчик; язык программирования; состояние разработки; аппаратная платформа; дата создания. Если каждая версия определяется единым набором атрибутов, нетрудно добавить новые версии, основанные на любой из существующих версий, поскольку они будут идентифицироваться единым набором значений атрибутов. При этом значения многих атрибутов новой версии будут совпадать со значениями атрибутов исходной версии; таким образом можно прослеживать взаимоотношения между версиями. Поиск версий осуществляется на основе значений атрибутов. При этом возможны такие запросы, как "самая последняя версия", "версия, созданная между определенными датами" и т.п. Например, обозначение для версии системы AC3D, разработанной на языке Java для использования под управлением Windows NT в январе 1999 года, будет выглядеть следующим образом: AC3D (язык = Java, платформа = NT4, дата = январь 1999). Идентификация, основанная на значениях атрибутов, системой управления версиями может применяться непосредственно. Однако более распространено использование только части имени версии, при этом база данных конфигураций поддерживает связь между значениями атрибутов и версиями системы и компонентов. Идентификация на основе изменений Идентификация, основанная на значениях атрибутов, устраняет проблему поиска версий, свойственную простым схемам нумерации, когда для поиска версии требуется знание ее атрибутов. Но в этом случае для регистрации взаимосвязей между версиями и изменениями необходимо использование отдельной системы управления изменениями. Идентификация на основе изменений применяется скорее к системам, чем к системным компонентам; версии отдельных компонентов скрыты от пользователей системы управления конфигурацией. Каждое изменение в системе описывается массивом изменений, где указаны изменения в отдельных компонентах, реализующие данное системное изменение. Массивы изменений могут применяться последовательно таким образом, чтобы создать версию системы, в которой реализованы все необходимые изменения. В этом случае не требуется точного обозначения версии. Команда управления конфигурацией работает с системой управления версиями посредством системы управления изменениями. Естественно, применение нескольких массивов изменений к системе должно быть согласовано, поскольку отдельные массивы изменений могут быть несовместимыми и их последовательное применение может привести к появлению неработоспособной системы. Кроме того, массивы изменений могут конфликтовать, если они предполагают разные изменения в одном компоненте. Для устранения этих проблем применяются средства управления версиями, поддерживающие идентификацию на основе изменений, что позволяет установить точные правила согласованности последовательности системных версий и что, в свою очередь, ограничивает способы комбинирования массивов изменений. 1.2. Управление выходными версиями. Выходной версией системы называется версия, поставляемая заказчику. Менеджеры по выпуску выходных версий отвечают за решение о дате выпуска, за управление процессом создания выходной версии, а также за создание документации. Выходная версия системы включает в себя не только системный код, но также ряд компонентов. Конфигурационные файлы, определяющие способ конфигурирования системы для каждой инсталляции. Файлы данных, необходимые для работы системы. Программа установки, которая помогает инсталлировать систему. Документация в электронном и печатном виде, описывающая систему. Упаковка и рекламные материалы, разработанные специально для этой версии системы. Менеджеры по выпуску выходных версий не могут быть уверены, что заказчики всегда будут заменять старые версии системы новыми. Некоторые пользователи вполне удовлетворены установленными у них версиями и считают, что установка новых версий не стоит затрат. Поэтому новые выходные версии системы не должны зависеть от предыдущих. Рассмотрим следующую ситуацию. Версия 1 системы находится в эксплуатации. Выпускается версия 2, требующая установки новых файлов данных. Однако некоторые пользователи не нуждаются в дополнительных возможностях версии 2 и продолжают использовать версию 1. Версия 3 требует файлов, содержащихся в версии 2, но сама не содержит этих файлов. Дистрибьютор ПО не может знать наверняка, что файлы данных, требующиеся для версии 3, уже установлены; некоторые пользователи будут переходить от версии 1 к версии 3, минуя версию 2. У других пользователей вследствие каких-либо обстоятельств файлы данных, связанные с версией 2, могут быть изменены. Отсюда следует простой вывод: версия 3 должна содержать все файлы данных. Принятие решения о выпуске выходной версии Подготовка и распространение программных систем требуют больших затрат, особенно это касается рынка массовых программных продуктов. Если выпуски выходных версий осуществляются слишком часто, пользователи не успеют осознать потребность в расширенных возможностях новых версий, а если выходные версии создаются редко, существует вероятность потери рынка сбыта, поскольку пользователи переходят к альтернативным системам. Это не относится к программным продуктам, созданным под заказ для определенной организации. Однако и тут редкие выходные версии могут привести к расхождению программной системы и тех бизнес-процессов, для поддержки которых система была разработана. Принятие решения о том, когда именно должна выйти следующая выходная версия системы, существенно зависит от технических и общих организационных факторов, которые описаны в табл. 15.1. Таблица 25.1. Факторы, влияющие на стратегию выпуска версий системы
Создание выходной версии Создание выходной версии – это процесс сбора всех необходимых файлов и документации, составляющих выходную версию системы. Требуется определить нужные исполняемые коды программ и файлы с данными. Конфигурация выходной версии должна определяться под конкретный тип аппаратных средств и операционной системы. Также нужно подготовить инструкции для пользователей по инсталляции системы, в том числе в электронном виде. Должны быть написаны сценарии для инсталляционной программы. В завершение создается инсталляционный диск, на котором будет распространяться система. В настоящее время в качестве носителей дистрибутивов наиболее широко распространены компакт-диски емкостью до 600 Мбайт. Документирование выходной версии Процесс создания выходной версии должен быть задокументирован, чтобы была возможность восстановить ее в будущем. Это особенно важно для больших систем с длинным жизненным циклом, разрабатываемых под заказ. Заказчики обычно используют одну версию системы на протяжении многих лет, и все необходимые изменения вносятся именно в эту версию через много лет после ее поставки. Для документирования выходной версии прежде всего необходимо записать версии исходного кода компонентов, которые использованы для создания исполняемого кода. Также следует собрать и сохранить все копии исходных и исполняемых кодов, системных данных и конфигурационных файлов. Кроме того, должны быть записаны версии операционной системы, библиотеки, компиляторы и другие средства, применяемые для сборки системы. 2. Сборка системы. Сборкой системы называют процесс компиляции и связывания программных компонентов в единую исполняемую программу. Перед сборкой системы полезно ответить на следующие вопросы. Все ли компоненты, составляющие систему, включены в инструкцию по сборке? Каковы версии компонента, перечисленные в инструкции по сборке? Доступны ли все необходимые файлы данных? Если на файлы данных используются ссылки внутри компонентов, то каковы имена этих файлов в выходной версии? Доступны ли нужные версии компилятора и других необходимых средств? Действующие версии программных средств могут быть несовместимы с более старыми версиями, которые применялись при разработке системы. В настоящее время существует много средств управления конфигурацией, автоматизирующих процесс сборки системы. Команда управления конфигурацией пишет сценарий, в котором определены зависимости между различными компонентами системы. В нем также указаны средства компилирования и связывания компонентов системы. Средства компоновки интерпретируют сценарий сборки системы и вызывают программы, необходимые для сборки исполняемой системы. Процесс сборки системы представлен на рис. 15.2.  Рис. 15.2. Сборка системы В сценарии сборки указаны зависимости между компонентами, поэтому компоновщик системы сам принимает решение, когда перекомпилировать компоненты, а когда можно многократно использовать существующий объектный код. Зависимости в сценарии сборки указаны в основном как зависимости между файлами, содержащими исходный код компонентов. Однако, если файлов с исходным кодом разных версий много, возникает проблема выбора нужных файлов. Проблема усугубляется, если файлы исходного и объектного кода имеют одинаковые имена (но, конечно, с разными расширениями). Чтобы избежать трудностей, связанных с зависимостью физических файлов, было разработано несколько экспериментальных систем, основанных на языках описания модулей. В них используется описание логической структуры ПО и схемы зависимостей между файлами, содержащими компоненты исходного кода. Такой подход снижает количество ошибок и приводит к более понятным описаниям процесса сборки системы. 3. CASE-средства для управления конфигурацией. Процесс управления конфигурацией обычно стандартизирован и включает выполнение заранее определенных процедур. Они требуют детализированного контроля за очень большим количеством данных. При сборке системы единственная ошибка в управлении может привести к некорректной работе системы. Поэтому очень важна поддержка процесса управления конфигурацией соответствующими CASE-средствами. Начиная с 70-х годов было разработано большое количество программных средств поддержки разных аспектов процесса управления конфигурацией. Примерами первого поколения средств управления конфигурацией могут служить системы SCCS и RCS, предназначенные для управления версиями и сборкой систем. Это автономные средства, которые поддерживали отдельные действия в процессе управления конфигурацией. Средства второго поколения, например Lifespan и DSEE, обеспечивают интегрированную поддержку процесса управления конфигурацией, однако некоторые этапы управления они не обеспечивали. Во время написания данной книги были доступны интегрированные пакеты CASE-средств, поддерживающие планирование управления, процессы управления изменениями, версиями и сборкой системы. Однако эти пакеты достаточно сложные, требуют усилий для изучения и освоения, поэтому многие организации-разработчики продолжают использовать средства поддержки первого и второго поколений. 3.1 Средства поддержки управления изменениями. Процесс управления изменениями заключается в заполнении форм запросов на изменения, проведении анализа изменений и передаче этих форм и соответствующих конфигурационных элементов команде управления качеством и команде по управлению конфигурацией. Этот алгоритмический по своей природе процесс позволяет сравнительно легко интегрировать его с системой управления версиями, поскольку, упрощая, можно сказать, что задача управления изменениями заключается в передаче нужных документов нужным людям в нужное время. Поэтому для поддержки процесса управления изменениями достаточно следующих средств. Редактор форм, позволяющий создавать и заполнять формы запросов на изменения. Система автоматизации документооборота, которая позволяет фиксировать закрепление обработки форм запросов на изменения за членами команды по управлению конфигурацией и определяет порядок этой обработки. Эта система может также автоматизировать процесс передачи заполненных форм "нужным людям в нужное время" и информировать о состоянии процесса внесения изменений. Как правило, эта система использует электронную почту для пересылки сообщений. База данных изменений, которая используется для хранения всех предложенных изменений и может быть связана с системой управления версиями. 3.2 Средства поддержки управления версиями. Управление версиями предполагает обработку больших массивов информации для регистрации изменений, вносимых в систему, и контроля за ними. Средства управления версиями обязательно включают репозиторий конфигурационных элементов, которые в дальнейшем не изменяются. Если необходимо изменить какой-либо конфигурационный элемент, находящийся в репозиторий, его копия помещается в рабочий каталог. После изменений новая версия элемента также помещается в репозиторий. Системы управления версиями могут отличаться друг от друга, но все они имеют базовый набор средств. Средство идентификации версий. Системы управления версиями могут поддерживать различные подходы к идентификации версий. Средство управления хранением версий. Чтобы уменьшить пространство, необходимое для хранения различных версий системы, которые могут быть значительных размеров, системы управления версиями используют специальные средства управления хранением, когда хранятся не сами версии, а их отличия от некоторой базовой версии. Различия между версиями представляются в виде дельты, где собраны инструкции, необходимые для воссоздания соответствующей версии системы. На рис. 15.3 показано, как из последней версии можно восстановить более раннюю версию системы.  Рис. 15.3. Восстановление версий Средство регистрации изменений. Регистрирует все изменения, сделанные в коде системных компонентов. В некоторых системах управления версиями это средство используется для поиска нужной версии системы. Средство поддержки параллельной разработки. Различные версии системы могут разрабатываться параллельно и изменяться независимо друг от друга. Система управления версиями должна отслеживать компоненты, которые изменяются, и контролировать, чтобы на один и тот же компонент не накладывались изменения, сделанные разными группами разработчиков. Некоторые системы позволяют единовременно изменять только один экземпляр компонента, другие автоматически разрешают возникшие коллизии, когда измененные компоненты возвращаются в систему управления версиями. 3.3 Средства сборки систем. Сборка систем - это очень трудоемкий вычислительный процесс. Например, процесс компиляции большой системы, состоящей из сотен компонентов, может занять несколько часов. Если компиляцию и связывание компонентов такой системы выполнять вручную, то оператор неизбежно сделает какие либо ошибки. Средства сборки систем автоматизируют этот процесс, что исключает потенциальные ошибки, совершаемые при ручном компилировании, и, возможно, сокращает время сборки системы. Средства сборки систем могут быть как автономными, например, соответствующие утилиты в системе Unix, так и интегрированными со средствами управления версиями. Как правило, CASE средства сборки систем состоят из следующих компонентов. Язык специфицирования зависимостей и соответствующий интерпретатор. Описывает и управляет зависимостями между системными компонентами и минимизирует возможные перекомпиляции. Средства выбора и реализации. Это компиляторы и другие средства работы с файлами исходного кода. Средства распределенной компиляции. Некоторые компоновщики систем, особенно распределенную (сетевую) компиляцию. Вместо выполнения всего процесса компиляции на одной машине компоновщик находит свободные процессоры в компьютерной сети и организует параллельную компиляцию. Это значительно сокращает время сборки системы. Средство управления вторичными объектами. Вторичные – это объекты, которые создаются на основе других, исходных, объектов. Средство управления такими объектами связывает исходный код и вторичные объекты и создает новые объекты только тогда, когда изменяется исходный код. Управление вторичными объектами и минимизацию количества перекомпиляций лучше всего объяснить на простом примере. Рассмотрим ситуацию, когда программа comp создается из объектных модулей scan.o, syn.o, sem.o и cgen.o. Для объектных модулей существуют модули, содержащие исходный код и имеющие имена соответственно scan.с, syn.c, sem.c и cgen.c. Эти модули используют общий файл объявлений defs.h. Зависимости между модулями показаны стрелками на рис. 15.4 (стрелки можно "прочитать" как "зависит от"). Допустим, в модуль scan.с внесены изменения. Система сборки должна определить, что вторичный объект scan.о необходимо создать заново, и вызвать соответствующий компилятор для перекомпиляции модуля scan.с и создания нового экземпляра объекта scan.o. Далее система сборки на основании связи между соmр и scan.o определяет, что необходимо заново создать также программу сотр путем связывания модулей scan.o, syn.o, sem.o и cgen.o. При этом система определяет, что объектный код других компонентов не изменялся, поэтому перекомпиляция их исходного кода не требуется.  Рис. 15.4. Схема зависимостей модулей Некоторые системы сборки используют дату изменения файла как ключевой атрибут, определяющий, требуется или нет перекомпиляция. Если дата изменения файла исходного кода более поздняя, чем дата изменения соответствующего файла объектного кода, то этот объектный код необходимо создать заново. Это гарантирует, что вторичный объект будет создан на основе самой последней версии исходного кода. Если перекомпилируется ранняя версия исходного кода, то изменяется дата ее модификации и система сборки по этой дате определяет, какие компоненты должны быть перекомпилированы или созданы заново. Другие системы сборки используют более сложные подходы к управлению вторичными объектами. Они вводят дополнительный атрибут для вторичных объектов, где указывается версия исходного кода, на основе которого создан этот объект, и по возможности сохраняются все версии вторичных объектов. Это позволяет иметь объектный код всех версий исходного кода без дополнительной перекомпиляции. КЛЮЧЕВЫЕ ПОНЯТИЯ Для управления конфигурацией необходима схема идентификации версий. Версии можно идентифицировать по номерам, на основе значений атрибутов и на основе изменений, внесенных в систему. Выходная версия системы включает исполняемый код, файлы данных, конфигурационные файлы и документацию. Управление выходными версиями предусматривает определение даты выпуска системы, подготовку всей информации для распространения системы и документирование каждой выходной версии. Сборка системы – это процесс компоновки системных компонентов в виде исполняемой программы. Для поддержки процесса управления конфигурацией применяются CASE-средства. Они включают средства для управления версиями и изменениями и средства для сборки системы. Контрольные вопросы: Для чего необходимо управление версиями и выпусками? Что вы понимаете по Версией системы? Что такое Выходная версия системы? Идентификация версий - это? Под нумерацией версий понимается …? Что вы понимаете идентификацией, основанной на значениях атрибутов? Создание выходной версии – это…? Документация выходной версии обозначает … ? Объясните суть Сборки системы. Литература для самостоятельного изучения: И. Соммервилл. Инженерия программного обеспечения. М. 2002. Стр. 593-602. |