Управление скриптами миграции или MyBatis Scheme Migration Extended

Я думаю, всем разработчикам так или иначе известно понятие “скрипт миграции”. Как правило, имеется ввиду sql-скрипт, созданный для поддержания актуальности БД. Путь создания и использования скриптов миграции весьма легок, поэтому вести этот процесс можно и вручную. Я же хочу рассказать об инструменте, который местами упрощает работу со скриптами миграции.

MyBatis Schema Migrations

В состав интересной библиотеки хранения данных MyBatis(ранее известной как iBatis) входит инструмент управления скриптами миграции. Он работает из командной строки и реализован как для Linux, так и для Windows систем. Консольный скрипт(bat, sh), с которым мы будем работать, всего лишь передает наши команды соответствующему java-классу и выполняет его на java-машине.
Что может библиотека:

1. Отображение списка скриптов миграции
2. Определение статуса конкретного скрипта миграции(уже накатан или ещё нет)
3. Отображение даты выполнения скрипта миграции
4. Создание шаблона скрипта миграции
5. Выполнение скриптов миграции
6. Откат изменений
7. Произвольное перемещение между версиями базы данных
8. Экспорт скриптов миграции в отдельный файл. При этом можно указать с какой до какой версии скриптов миграции стоит выполнить экспорт.

При первом запуске MyBatis Schema Migrations заботливо может создать структуру проекта скриптов миграции, которую он понимает.
Процесс работы с утилитой выглядит так (все команды выполняются в контексте запуска самого инструмента в формате migrates <<команда>>):

1. Инициализируем репозиторий скриптов миграции командой init
2. Создаем скрипт миграции, указывая имя скрипта командой new
3. В созданной заготовке скрипта есть два блока. Заполняем их:
   • Сам скрипт миграции
   • Скрипт отката изменений текущей миграции
4. Прогоняем скрипты миграции командой up
5. Смотрим статус скриптов командой status
6. Если есть скрипты(например, появились после обновления проекта через систему контроля версий), прогоняем их командой up
7. Если нужно вернуться к определенному состоянию базы, то мы откатываем изменения командой down или version
8. Экспортируем кучу наших скриптов миграции в отдельный файл, например, чтобы отдать заказчику командой scripts fromVersion toVersion, где fromVersion и toVersion определяют диапазон экспортируемых данных
9. В случае появления невыполненных скриптов в середине списка, можно прогнать только их с помощью команды pending. Команда опасна тем, что от измененного скрипта могут зависеть другие скрипты.

Вот так просто можно контролировать состояние базы данных проекта.
Но не обошлось и без тонкостей. Так, у меня из под linux’а эта утилитка отказалась находить шаблон скриптов миграции по-умолчанию. Пришлось прописывать в конфигурационном файле(migration.properties) путь к своему файлу шаблона:
new_command.template=20110925094101_first_migration.sql
Выполнять команды утилиты нужно, находясь в проекте скритов миграции, который мы создали командой init. Так же можно находится где угодно, но приписывать к каждой команде параметр --path.
Более подробно о работе с MyBatis Schema Migrations можно узнать из официального tutorial’а и из официального видео, где показывается пример работы с инструментом.

MyBatis Schema Migrations Extended (Migro)

Хотя утилита показалась мне интересной и некоторые проблемы она решает, но в текущей реализации мне видятся и минусы, которые появятся с внедрением этого инструмента. Проект написан на java и распространяется под лицензией Apache License 2, что натолкнуло меня на мысль о создании своего форка этого проекта, где я мог бы реализовать необходимые фичи. Скажу сразу, что я считаю проект myBatis migration tool вполне законченным и я понимаю видение его разработчиков о ведении скриптов миграции. Но у меня свое видение на этот счет и я считаю, что для использования на больших проектах этот инструмент не совсем подходит.

О том что нужно для большого проекта

Что уже реализовано в моем проекте:

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

Что будет реализовано:

• Управление группировкой по версиям билдов из командой строки
• Выполнение определенного скрипта миграции или произвольный диапазон
• Экспорт скриптов, конкретной версии билда
• Экспорт скриптов в шаблонный файл
• Интеграция с IDE
• Оптимизация и рефакторинг:)

Скачать можно здесь: https://github.com/evgenij-kozhevnikov/Migro
Проект-источник: myBatis
Видео: Пример использования myBatis Scheme Migration