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

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

    - с проверкой работоспособности системы после скачивания (pull) и слияния (merg) изменений с сервера; - с идентификацией ошибки (в случае наличия); - с поиском сохраненного Data Definition Language (далее - DDL) запроса в соответствующей папке; - с выполнением запроса для нивелирования различий в структурах баз данных либо через графический интерфейс системы управления базой данных (далее - СУБД), либо непосредственно через командную строку СУБД; - с ситуацией, когда несколько сотрудников изменили структуру БД в одном и том же месте. В этом случае человек, который пытается применить изменение на сервере, не сможет этого сделать из-за расхождений с эталонной базой; - с ситуацией, когда один из сотрудников изменил структуру БД, но забыл добавить соответствующий DDL запрос в папку или неправильно его оформил; - с ошибками программирования.

В отделе разработок компании в настоящее время работают 11 программистов. У каждого сотрудника есть свое рабочее место - ПК или ноутбук, на котором установлены:

    - операционная система (Windows); - локальный сервер (Apache2.4 или IIS); - интерпретатор языка Personal Home Page (PHP) (v.5.4); - система управления базами данных (СУБД) (MySQL 5.6); - графическое приложение для работы с СУБД (HeidiSQL v.9.3); - текстовый редактор (SublimeText v.3.0); - система контроля версий Mercurial (Tortoise HG v.3.5).

Помимо этого есть общий сервер (production), работающий на Linux Debian, на котором также установлены:

    - интерпретатор языка PHP (v.5.4); - СУБД MySQL (5.6); - система контроля версий Mercurial (Tortoise HG v.3.5).

Структура БД на сервере является эталонной.

По мере необходимости программисты добавляют (удаляют, изменяют) поля, данные, индексы, триггеры, хранимые процедуры, представления, формируя из Data Manipulation Language (далее - DML) или DDL - запросов (changesets) текстовые файлы, которые сохраняются в отдельную папку. Затем происходит фиксация проделанной работы через систему контроля версий и изменения "выкладывается" на сервер. Далее, на сервере выполняется сохраненный changeset. Таким образом, структура БД на сервере изменяется.

Остальные программисты скачивают изменения с сервера, производят слияние (merge) и формы становятся у всех идентичными (в том числе и папка с сохраненными changeset-ами).

Однако структура БД остается разной, по сравнению со структурой БД на сервере, и для того чтобы избавиться от этого необходимо выполнить сохраненный sql-запрос того пользователя, который инициировал изменение БД. Но на практике регулярно происходят следующие ситуации:

    - пользователь, скачавший изменение с сервера, не посмотрел, какие файлы были изменены, т. к. каждый программист занимается своей частью работы; - пользователь, сделавший фиксацию изменений (commit) забыл добавить sql-файл на изменение БД; - пользователь, скачавший изменение с сервера, не увидел, пропустил sql-файл, т. к. каждый программист, в течение дня может проводить фиксацию работы по несколько раз и не регулярно "заливать" изменения на сервер, так же как "сливать" изменения с сервера, таким образом, при скачивании образуется порядка 10-12 фиксаций, которые необходимо просмотреть.

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

Актуальность задачи можно обосновать следующим образом:

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

Создание системы позволит:

    - снять с программистов необходимость отдельно фиксировать изменения в структуре БД; - отслеживать изменения сделанные другими сотрудниками; - освободит время на поиск и устранение ошибок, связанных с версионной миграцией БД; - позволит хранить историю изменения БД в xml файлах; - позволит мигрировать структуру рабочей БД на любую другую СУБД.

Со стороны организации ООО "БРеалИТ" (далее заказчик) к разрабатываемой АИС были предъявлены следующие требования:

    - Должна иметь настройку запуска: запускаться сразу после скачиваний изменений с сервера или по решению пользователя. - Должна предоставлять пользователю удобочитаемую информацию о результатах проделанной работы. - Должна предоставлять пользователю выбор действий (выполнить запросы сейчас или отложить выполнение). - Для переносимости между различными СУБД, структура БД должна храниться в XML-файле. - Файлы со структурой БД и историей ее изменения должны находиться под СКВ чтобы, в случае необходимости, можно было откатиться на предыдущую ревизию. - Должна генерировать SQL код и выводить его в удобочитаемом виде, который можно было бы выполнить прямо из системы. - Должна иметь возможность сравнения структуры выбранной БД и файла со структурой БД. - Должна быть с открытым исходным кодом и давать возможность вносить изменения в программу. - Должно быть руководство пользователя. - Должна быть бесплатной. - Должна быть кроссплатформенной.

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

Compalex.

внешний вид окна с результатом работы программы compalex

Рис. 1 -- Внешний вид окна с результатом работы программы Compalex

Система Compalex (Рис. 1) сравнивает структуру двух баз данных, результат сравнения выводит пользователю через графический интерфейс. Однако данная программа предназначена исключительно для сравнения структуры БД и:

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

LIQUIBASE

логотип программы liquibase

Рис. 2 -- Логотип программы Liquibase

Система LIQUIBASE (Рис. 2) позволяет вести изменение БД. История изменений хранится в xml файле. Однако данная программа:

    - не позволяет сравнивать структуру двух разных баз; - работает с СКВ Git, а проект заказчика поддерживается системой контроля версий Mercurial; - является платной; - имеет сложный синтаксис выполнения команд (Рис. 3); - недостаточная документация по системе.
пример ввода команды в программе liquibase

Рис. 3 -- Пример ввода команды в программе Liquibase

Flayway.

логотип программы flayway

Рис. 4 -- Логотип программы Flayway

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

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

Rails

логотип программы rails

Рис. 5 - Логотип программы Rails

Система Rails (Рис. 5) позволяет сравнивать две базы данных, история изменений хранится в отдельном файле, работает через интерфейс командной строки, быстро выполняется скрипт, позволяет абстрагироваться от конкретной СУБД. Однако, имеет ряд особенностей, из-за которых не может использоваться в качестве решения поставленной задачи:

    - написана на языке программирования Ruby, а в ООО "БРеалИТ" (компания - заказчик) нет штатной должности по данному направлению и поддержка системы "своими силами" не представляется возможной; - имеет сложное руководство пользователя.

Dbdeploy.

Рис. 6 - Логотип программы Dbdeploy

Dbdeploy (Рис. 6) хранит всю историю изменений в отдельных xml файлах, имеет открытый исходный код. Из минусов:

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

MySQL Workbanch.

логотип программы mysql workbanch

Рис. 7 - Логотип программы MySQL Workbanch

MySQL Workbanch (Рис. 7) является программой для управления базами данных MySQL и MSSQL и может использоваться в качестве графического интерфейса. Позволяет сохранять изменения базы данных, не запуская дополнительного ПО, имеет отличную документацию и техническую поддержку, но имеет ряд недостатков, не позволяющих использовать данное решение в конкретной задаче:

    - не хранит структуры БД в xml документе; - не работает через командную строку; - компания - заказчик использует другое ПО для управления базой данных; - инструмент миграции выполнен в качестве библиотеки к MySQL Workbanch.

MySQL Migration with PHP.

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

    - создавать ALTER (CREATE, DROP) скрипты в читабельном виде; - хранить структуру базы данных в xml файле; - работать под контролем СКВ.

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

Похожие статьи




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

Предыдущая | Следующая