W010606 Дипломная работа Разработка автоматизированной системы контроля версий базы данных

СОДЕРЖАНИЕ

ВВЕДЕНИЕ 2

1. Системы контроля версий 4

1.1 Общие сведения о системах контроля версий 4

1.1.1 Определение и применение 4

1.1.2 Типичный порядок работы с системой 6

1.1.3 Конфликты и их разрешение 12

1.1.4 Блокировки 13

1.1.5 Версии проекта, тэги 16

1.1.6  Базовые принципы разработки ПО в VCS 18

1.1.7 Распределённые системы управления версиями 19

1.2 Проблема версионирования баз данных 24

1.3 Обзор и сравнение систем контроля версий баз данных 25

2. Применяемые методы для контроля версий БД 31

2.1 Метод инкрементных изменений 31

2.2 Метод идемпотентных изменений 34

2.3 Метод уподобления структуры базы данных исходному коду 38

3 РЕАЛИЗАЦИЯ СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ БД 42

3.1 Описание инструментов 42

3.2 Описание функций приложения 46

ЗАКЛЮЧЕНИЕ 56

БИБЛИОГРАФИЯ 59

ВВЕДЕНИЕ

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

С целью оптимизации труда программисты автоматизировали процесс контроля версий базы данных, для чего были созданы различные системы контроля версии кода программы. Однако именно контролю версий для структуры базы данных было уделено достаточно мало внимания, хотя структура баз данных также часто подвержена изменениям из-за изменений и дополнений требований к разрабатываемому проекту. В связи с этим считаем актуальным разработать автоматизированную систему контроля версий структуры БД. Наиболее популярной СУБД для web приложений является сегодня СУБД MySQL, поэтому в нашей работе будем ориентироваться на неё.  

Объект исследования нашей работы – структура базы данных.

Предмет – контроль версий структуры базы данных.

Цель нашей работы – разработка автоматизированной системы контроля версий базы данных.

Исходя из поставленной цели, ставим перед собой следующие задачи:

- рассмотреть общие сведения о системах контроля версий,

- выявить проблемы версионирования баз данных,

- провести обзор и сравнение систем контроля версий баз данных,

- изучить методы для контроля версий баз данных,

- провести реализацию систем контроля версий баз данных.

Методы, используемые в нашей работе, - анализ литературы, посвященной данной проблеме, детальное изучение предметной области.

Инструменты -  Java, СУБД MySQL5, IDE-NetBeans.

Наша работа состоит из трех глав: первая посвящена теоретическим аспектам, вторая – методическим и третья – практическая часть.

1. СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ

1.1 Общие сведения о системах контроля версий

1.1.1 Определение и применение

Система, позволяющая хранить несколько версий одного и того же документа, а также работать с первоначальными его вариантами, называется системой управления версиями или VCS (в переводе с англ. Version Control System или Revision Control System). Данные системы наиболее широко используются при разработке программного обеспечения с целью хранения исходных кодов разрабатываемой программы.

Кроме того, системы управления версиями могут применяться в тех областях, где ведётся работа с большим количеством непрерывно изменяющихся электронных документов. К примеру, они активно используются в САПР в составе систем управления данными об изделии (PDM). Управление версиями используется и в инструментах конфигурационного управления.

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

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

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

В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и является всегда доступной. Сервер может использовать способ хранения документов, при котором сохраняются только изменения между последовательными версиями, что позволяет уменьшить объём хранимых данных. Такая функция получила название дельта-компрессии [7, с.32].

Некоторые системы, например, ClearCase, поддерживают сохранение версий обоих видов: большинство версий сохраняется в виде дельт, но периодически (по специальной команде администратора) выполняется сохранение версий всех файлов в полном виде. Такой подход обеспечивает максимально полное восстановление истории в случае повреждения репозитория.

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

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

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

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

Системы управления версиями предоставляют следующие возможности:

- создание разных вариантов одного и того же документа,

- возможность отслеживания изменений (кем и когда были добавлены изменения в конкретный набор строк в файле);

- ведение журналов изменений, где пользователи могут записывать обоснования своих изменений;

- контроль права доступа пользователей, разрешение или запрещение чтения или изменения данных [4, с.118-120].

1.1.2 Типичный порядок работы с системой

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

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

По команде извлечения устанавливается соединение с сервером и проект или его часть в виде дерева каталогов и файлов копируется на компьютер разработчика. Рабочая копия параллельно дублируется на локальный диск (либо в отдельный, специально выбранный каталог, либо в системные подкаталоги основного дерева проекта).

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

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

Модификация проекта

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

Фиксация изменений

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

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

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

Значительные изменения производятся с помощью создания ветвей (branch), то есть «отпочковывания» от ствола в какой-то версии нового варианта проекта или его части, разработка в котором ведётся параллельно с изменениями в основной версии. Ветвь создаётся специальной командой. Рабочая копия ветви может быть создана заново командой извлечения рабочей копии, с указанием адреса или идентификатора ветви, либо путём переключения имеющейся рабочей копии на заданную ветвь.

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

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

Три вида операций в системе управления версиями ведут к необходимости объединения изменений:

- обновление рабочей копии (изменения, сделанные в основной версии, сливаются с локальными);

- фиксация изменений (локальные изменения сливаются с изменениями, уже зафиксированными в основной версии);

- слияние ветвей (изменения, сделанные в одной ветви разработки, сливаются с изменениями, сделанными в другой).

Для всех указанных случаев характерны черты:

- ранее была сделана копия дерева файлов и каталогов репозитория или его части;

- впоследствии и в оригинальное дерево и в копию были независимо внесены некоторые изменения;

- требуется объединить изменения в оригинале и копии таким образом, чтобы не нарушить логическую связность проекта и не потерять данные [10, с.245-247].

Если изменения были внесены только в оригинал или только в копию объединение достигается путем копирования изменённой части туда, где изменений не было. В противном случае слияние изменений требует вмешательства разработчика.

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

- изменения могут состоять в модификации содержимого файла, создании нового файла или каталога, удалении или переименовании ранее существовавшего файла или каталога в проекте;

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

- создание, удаление и переименование файлов в каталогах проекта могут быть объединены автоматически, если только они не конфликтуют между собой. В этом случае изменения, сделанные в каждой версии проекта, копируются в объединяемую версию [14, с.112-115].

Конфликтующими обычно являются:

- удаление и изменение одного и того же файла или каталога;

- удаление и переименование одного и того же файла или каталога (в случае, если система поддерживает операцию переименования);

- создание в разных версиях файла с одним и тем же именем и разным содержимым.

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

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

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

При определении допустимости слияния изменений в пределах одного и того же текстового файла работает типовой механизм построчного сравнения текстов. Пример его реализации - системная утилита GNU diff, которая сравнивает объединяемые версии с базовой и строит список изменений [10, с.95-96].

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

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

1.1.3 Конфликты и их разрешение

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

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

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

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

Виды конфликтов мы можем увидеть на рис.1.

Рис.1. Виды конфликтов [4, с.135]

Одним из видов решения является блокировка. Её суть рассмотрим в следующем разделе нашей работы.

1.1.4 Блокировки

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

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

Если файл помечен как блокируемый, то при извлечении рабочей копии с сервера он получает в локальной файловой системе атрибут «только для чтения», а значит изменить его невозможно. Разработчик, желающий изменить блокируемый файл, вызывает специальную команду блокировки (lock) с указанием имени этого файла. Работа этой команды строится по принципу:

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

- файл на сервере помечается как «заблокированный», с сохранением идентификатора заблокировавшего его разработчика и времени блокировки;

- если блокировка на сервере прошла удачно, на локальной файловой системе с файла рабочей копии снимается атрибут «только для чтения», что позволяет начать его редактировать.

При работе разработчика с заблокированным файлом может оказаться, что файл изменять не нужно. В этом случае разработчик может вызвать команду снятия блокировки (unlock, release lock). Все изменения файла будут отменены, локальный файл вернётся в состояние «только для чтения». С файла на сервере будет снят атрибут «заблокирован» и другие разработчики получат возможность изменять этот файл.

По завершении работы с блокируемым файлом разработчик фиксирует изменения. Файл после изменений теряет флаг «заблокирован» и может быть изменён другими разработчиками. Блокировки изменение представлены на рис.2.

Рис.2. Блокировки-изменение [4, с.158].

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

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

Блокировки создают и административные проблемы. Типичный пример: разработчик может забыть снять блокировку с занятых им файлов, уходя в отпуск. Для разрешения подобных проблем приходится применять административные меры, в том числе включать в систему технические средства для сброса неверных блокировок.

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

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

1.1.5 Версии проекта, тэги

Система управления версиями обеспечивает хранение всех существовавших вариантов проекта. Само понятие «версии» в разных системах может трактоваться двояко.

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

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