Flyway что это такое
Контроль версий в базах данных — Сравнение Liquibase и Flyway
Автоматизированный рефакторинг баз данных должен быть частью жизненного цикла разработки наших продуктов наряду с рефакторингом любых других программных компонентов. Исторически так сложилось, что контроль версий исходников покрывал в подавляющем большинстве случаев только так называемый прикладной код (например, Java), исключая SQL, скрипты на котором носили внешний характер и применялись к целевым базам данных, минуя контроль версий.
Тем не менее, в связи с ростом популярности аджайл методологии в последние годы и востребованностью непрерывной интеграции и развертывания, мы больше не можем ограничивать применение CI/CD только к коду приложения, оставив SQL позади.
В аджайл проектах тех требования вырабатываются спринт за спринтом, поэтому очень маловероятно, что вы сможете с самого начала точно угадать со структурой модели базы данных. Модель базы данных развивается по мере формирования продукта. Многие команды и компании разрабатывают собственные процессы контроля версий баз данных, подходящие сугубо для целей их собственных продуктов, но существуют и общие решения, уже приобретшие статус отраслевых стандартов. Им мы и уделим внимание в этой статье.
Ниже будут рассмотрены сходства и различия ныне хорошо известных продуктов Flyway и Liquibase.
Как работают инструменты Flyway и Liquibase
Оба инструмента реализуют концепцию эволюционных баз данных, — объясняет Мартин Фаулер.
Вы начинаете с пустой модели базы данных, для которой таблица контроля версий (специфичная для каждого инструмента) также пуста, и еще не были применены никакие скрипты. Затем вы применяете несколько скриптов (Script1 и Script2) и в итоге получаете первую версию базы данных. Скрипты 3 и 4 регистрируются в таблице контроля версий, и мы получаем вторую версию базы данных. Вы всегда знаете имя автора, имя скрипта и его контрольную сумму.
Пример кода
1.Создайте пустой проект maven
2. Установите плагин Flyway в pom.xml (и базу данных H2, чтобы мы запускали на ней пример).
3. Определите файл конфигурации flyway
4. Создайте первый скрипт миграции
5. Выполните первую миграцию
Вывод должен быть следующий
Вы также можете проверить базу данных
Просто запустите его снова
7. Примените вторую миграцию
8. Что произойдет, если я изменю уже примененный скрипт?
Измените в уже существующем примененном файле V2_Addpeople.sql.sql
Повторный запуск миграции покажет, что Flyway заметил изменение контрольной суммы и не пропустил новую миграцию.
Если вы хотите изменить имя этого человека, вам нужно добавить еще один файл, третий, с командой обновления имени этого человека.
Возможности, предлагаемые Flyway и Liquibase
Как Flyway, так и Liquibase являются инструментами, написанными на Java. Они легко интегрируются с maven, gradle и другими инструментами сборки, что способствует большей кастомизации. Они предлагают Java API и могут быть расширены. Их можно использовать из командной строки или используя их jar параметры.
Оба продукта предлагают
инкрементное развертывание скриптов (только в случае еще не примененных к целевой базе данных скриптов)
предотвращение ситуаций, когда скрипт, примененный к базе данных, был изменен в системе контроля версий вместо инкрементного добавления
решения для коррекции развертывания или исправления ситуации, когда скрипт был неправильно изменен
оба полагаются на таблицы контроля версий с контрольной суммой (Flyway: SCHEMA_VERSION, Liquibase: DATABASECHANGELOG и DATABASECHANGELOGLOCK)
baselining — если ваша схема базы данных уже была создана без использования какого-либо из этих инструментов, но вы захотите начать деплоить с их помощью спустя некоторое время после ее создания, вы можете использовать baseline-команды для создания бейслайна схемы поверх которого можно быдет инкрементно добавлять новые скрипты. Бейслайн будет включать DDL, но не данные. Иногда разработчики, запускающие инструмент в первый раз, оказываются сбиты с толку, думая, что бейслайн также мигрирует данные.
В таблице ниже перечислены некоторые из наиболее важных и часто используемых фич этих продуктов. В таблице указаны версии инструментов с открытым исходным кодом, распространяемые по бесплатной лицензии, каждая из которых имеет коммерческие версии с расширенным функционалом.
Общие сценарии использования для FlyWay и Liquibase
Оба инструмента предлагают все мощные функции, необходимые для полной автоматизации рефакторинга и эволюционной модели базы данных. Они легко интегрируется в экосистему Spring, хорошо работают с maven, gradle, java.
Вам следует использовать эти инструменты для обеспечения
контроля версий для всех артефактов баз данных
аудита изменений модели базы данных
чтобы каждый в команде имел собственное развертывание базы данных
предотвращать развертывания, когда база данных не синхронизирована с приложением
создавать новые среды
заставлять разработчиков непрерывно интегрировать свой код базы данных
Когда следует использовать Flyway, а когда Liquibase
В Liquibase есть автоматически генерируемые скрипты отката, если вы используете xml-теги, которые позволяют автоматически генерировать откат. Сюда входят простые теги, такие как создать таблицу, добавить столбец и т. д., для которых движок может легко определить откат. Для более сложных скриптов со сложной бизнес-логикой, с использованием тегов Liquibase внутри, вам нужно писать откаты самостоятельно.
Также я использовал DIFF в Liquibase, которого нет в Flyway, он позволяет сравнивать две схемы базы данных и определять их различия.
Также вы можете сделать одну вещь с помощью обоих инструментов — встроить создание обязательных скриптов отката в процесс CI/CD. В одном из моих проектов при каждом pull-реквесте инкрементальных скриптов базы данных сервер сборки выполнял сборку pull-реквеста, в рамках которой мы выполняли и скрипты отката для выделенной схемы CI. Если для одного скрипта не предусмотрен откат, или если выполнение отката завершилось неудачно, сборка завершалась ошибкой.
Ограничения
У каждого инструмента есть свои ограничения. Некоторые из них не актуальны в коммерческих версиях (например, атомарный откат в Flyway доступен только в коммерческой версии).
Тем не менее, вкратце, это единственные ограничения, с которыми я столкнулся в своем опыте работы с обоими инструментам:
Вам нужно всегда использовать инструмент при развертывании. Если вы работаете в компании, в которой некоторые команды не хотят работать с этим инструментом, а вместо этого применяют скрипты вручную, ничего не получится.
Baselining с данными невозможен. Это связано с тем, что средства этих инструментов не связаны с миграцией данных, поэтому разумно не определять базовый уровень данных, а использовать соответствующие специальные задачи DBA для выравнивания данных.
На правах рекламы
А прямо сейчас в OTUS действует новогодняя скидка на все курсы. Рекомендуем обратить внимание:
Использования FlyWay для баз данных на примере Maven
Привет Хабровчане и Хабровчановки!
Хочу рассказать о очень удобном и полезном инструменте под названием FlyWay. На самом деле статьи уже были на нашем любимом ресурсе, но в последнее время произошли некоторые достаточно существенные изменения, поэтому свежая порция информации не помешает я думаю.
Что же такое FlyWay?
Как говорит официальная страница «Welcome to Flyway, database migrations made easy.», что не может быть неправдой.
Количество поддерживаемых баз довольно приятное:
Для подключения FlyWay к проекту в pom.xml необходимо добавить новую часть простынки, вида примерно такого:
Настроек для плагина кроме этих огромное количество, доступны в документации, я использую только эти на данный момент, ну и еще парочку. Кастомизировать можно фактически все что угодно, подключить несколько схем и тд и тп.
Далее, важно верное именование скриптов. Так как миграции происходят последовательно, необходимо сохранять версионирование. Имена должны иметь вид V1_1__some_text.sql для первого скрипта, далее для второго V1_2__else_text.sql для второго и так далее. Обязательно обратить внимание на двойное подчеркивание перед текстом, это необходимое требование к имени!
Собственно, подключили мы плагин, создали пару скриптов и к работе уже готовы.
Предположим, что проект начат, какие то данные залиты, хотим все привести в порядок и автоматически далее накатывать.
Приводим скрипты к описанному выше виду, проверяем их на работоспособность ( а как же без этого), далее делаем mvn flyway:clean и получаем чистую базу. Далее используем mvn flyway:migrate и вуаля, получаем ее в том виде, как было до clean.
Затем, по прошествии времени, появляется необходимость добавления данных. Если берем пример выше, у нас к примеру было 2 скрипта, создаем третий с именем V1_3_something.sql и снова проводим mvn flyway:migrate. Flyway определяет, что появился новый скрипт и донакатывает его на нашу базу.
Очень важно обратить внимание, что если были внесены изменения в V1_1 или V1_2, не произведены какие то действия, затем добавлено V1_3 и запущена миграция, то ничего не выйдет. Необходимо соблюдать неизменяемость предыдущих скриптов.
Конечно, в вышеописанной ситуации может помочь repair либо baseline, но не всегда, есть определенные ограничения накладываемые на базу данных, например первая строка официальной документации по repair сообщает нам условие «Remove failed migration entries (only for databases that do NOT support DDL transactions)». Важно обращать на это внимание.
На личном опыте, при использовании OracleBD при ошибке в накатке последнего скрипта помогает baseline.
На данный момент количество скриптов дошло в моем проекте до V3_21, первую цифру меняем в зависимости от проекту, вторую по количеству новых изменений. Проблем не возникает, если необходимо раскатать новое окружение, использую Jenkins, запуск Job и все. Естественно в pom.xml используются профили и их всего несколько — локальный хост, новый хост, обновление старого хоста. Достаточно быстро и удобно.
Вообще, как полагается у хороших людей, официальная документация, довольно подробная, с картинками, наглядно объясняющими что да как, да хорошими примерами, но для того, чтобы сделать первый шаг, описанного в статье будет уже достаточно.
Инструментарий для рефакторинга баз данных: Flyway vs. Liquibase
В этой статье мы поговорим о Flyway и Liquibase — двух наиболее популярных инструментах на основе Java для рефакторинга баз данных. Цель статьи — сравнить эти инструменты и выяснить, какой из них в каких случаях лучше применять.
Flyway
Концепция Flyway сосредоточена вокруг шести различных команд для поддержки автоматизированного рефакторинга и версионирования БД. Эти команды могут исполняться из командной строки, в процессе сборки (производимого с помощью Maven или Gradle) или непосредственно из Java-кода с помощью вызовов API. При исполнении этих команд вам необходимо предоставить параметры подключения к той БД (url, имя пользователя, пароль), которую вы хотите рефакторить.
Основная команда называется migrate и выполняет функцию, в которой заключается вся суть рефакторинга БД: она сканирует специальную папку с sql-скриптами (у каждого из которых в имени файла указан номер версии) и проверяет, какие из них уже применялись к целевой базе данных. Затем она исполняет те из них, которые еще не применялись к этой БД. В случае возникновения противоречий, например, если уже примененный скрипт изменился со времени его применения, Flyway прерывает процесс своей работы сообщением об ошибке.
Уникальной чертой Flyway является то, что скрипты миграции могут быть не только в формате SQL, но и в виде Java-кода. Второй вариант позволяет реализовывать динамические миграции со сложной логикой. Однако использовать Java-подход следует с осторожностью, так как подобные скрипты миграции обычно тяжело дебажить, если в них что-то пошло не так.
Помимо основной команды migrate у Flyway есть дополнительные команды, облегчающие процесс рефакторинга БД.
Команда info показывает все доступные скрипты миграции из заданной папки и отмечает, какие из них уже были использованы, а какие только будут применены к целевой БД.
Если вы считаете, что скрипты нужно применять несмотря на сбой, показанный командой validate, то можно запустить команду repair. Она сбросит таблицу БД, используемую Flyway для фиксации того, какие скрипты были уже применены (по умолчанию эта таблица называется SCHEMA_VERSION).
И последняя, но не менее важная, команда clean полностью очищает выбранную схему (как вы понимаете, эта команда должна использоваться только для тестовых БД).
Liquibase
Liquibase использует другой подход к реализации рефакторинга БД. В отличие от Flyway, которая поддерживает скрипты миграции только в форматах SQL и Java, Liquibase позволяет абстрагироваться от SQL и таким образом устранить привязку рефакторинга базы данных к ее конкретной реализации.
Вместо SQL-скриптов, Liquibase поддерживает скрипты миграции в форматах XML, YAML и JSON. В этих скриптах вы определяете изменения в БД на уровне абстракций. Для каждого изменения Liquibase имеет соответствующий элемент в XML, YAML и JSON. Например, изменение, создающее новую таблицу БД в формате YAML выглядит так:
В каких случаях их использовать?
И Flyway, и Liquibase поддерживают все функции, необходимые для профессионального рефакторинга и версионирования БД, так что вы всегда будете знать, с какой версией схемы БД вы имеете дело и соответствует ли она версии вашего ПО. Оба тула интегрированы с Maven и Gradle и в экосистему Spring Boot, так что рефакторинг БД можно полностью автоматизировать.
Flyway использует SQL для определения изменений БД, так что можно настроить SQL-скрипты так, чтобы они эффективно работали с конкретными типом базы данных на вашем проекте, например с Oracle или с PostgreSQL. С другой стороны, Liquibase вводит дополнительный уровень абстракции с помощью XML, YAML или JSON для определения изменений БД. Таким образом, Liquibase лучше подходит для ПО, которое нужно устанавливать в разных окружениях с разными типами серверов БД. Однако если вам нужен полный контроль над вашим SQL, ваш выбор — Flyway, так как он позволяет изменять БД с помощью полностью кастомного SQL или даже с использованием Java-кода.
Подвох с обоими инструментами в том, что они поддерживаются одним человеком (от переводчика: по информации автора), а не большой командой. Это может оказать негативное влияние на будущее развитие обоих тулов, однако это не обязательно. На момент написания этой статьи активность в GitHub-репозитории Flyway выше, чем в репозитории Liquibase.
Flyway: управление миграциями баз данных
В этой статье я расскажу об одном из средств обеспечения версионности схем и управления миграциями БД — библиотеке Flyway. С поблемой версионности схемы базы данных рано или поздно приходится сталкиваться разработчикам любого приложения, опирающегося на СУБД. Увы, иногда эта проблема принимается в рассмотрение слишком поздно — например, если вопрос о внесении изменений в структуру базы встаёт, когда приложение уже находится в эксплуатации. Но и на этапе разработки контроль схемы базы данных причиняет не меньше проблем, чем все прочие аспекты версионности приложения: в отсутствие чёткой системы управления миграциями локальная, стендовая и эксплуатационная базы могут быстро «разъехаться», не предоставляя при этом никакой информации относительно своего текущего состояния.
Перзистенс-провайдеры штатно позволяют лишь в том или ином виде экспортировать актуальную объектную модель в виде схемы базы данных. Этот процесс может быть выполнен в режиме пересоздания (с полным удалением всей структуры), обновления (с внесением изменений) или сверки (без внесения изменений). Например, в Hibernate это делается с помощью инструмента hbm2ddl, работа которого может быть настроена единственным конфигурационным параметром в файле hibernate.cfg.xml или persistence.xml. Однако пересоздание (режим create) бывает нежелательным, если в базе уже есть данные, а обновление (режим update) вносит не все изменения, а только недеструктивные (например, не удаляются столбцы и таблицы) и не учитывает требующуюся реструктуризацию данных. Зачастую, если модель данных претерпела множество изменений, применить их к эксплуатационной базе бывает непросто, особенно если текущая версия базы неизвестна. Так или иначе, но приходится «опускаться» до SQL-скриптов — тут-то и встаёт вопрос управления версионностью.
Flyway
На главной странице проекта приведена наглядная таблица сравнения библиотеки с аналогичными решениями, и здесь основное внимание хочется обратить на богатую функциональность, работу с миграциями в виде простых SQL-файлов или Java-классов (последние по сути основываются на Spring JDBC Template) и поддержку нативного SQL популярных СУБД (Oracle PL/SQL, SQL Server T/SQL, хранимые процедуры MySQL и PostgreSQL).
Flyway хорошо интегрируется с Ant, Maven и инструментами командной строки, имеет API для программного вызова и интеграцию со Spring, работает со множеством СУБД. Я приведу пример подключения Flyway к уже существующему проекту, сборка которого основывается на Maven, а вызов Flyway производится при старте контекста Spring. В качестве базы данных в проекте используется MySQL.
Подключение Flyway к проекту
Для начала создадим папку db/migration в подкаталоге src/main/resources проекта: в ней будут храниться скрипты миграции. Поместим туда предварительно экспортированный скрипт базы данных — со всеми таблицами, представлениями, индексами и т.д. Назовём файл V1__Base_version.sql. Подробно соглашения по именованию миграций описаны в документации, пока достаточно сказать, что имя файла начинается с V, далее следует номер версии (с произвольным количеством точек-разделителей), двукратный символ подчёркивания и описание миграции.
Добавим в зависимости проекта (раздел dependencies) ядро библиотеки Flyway:
А в сборочные плагины (раздел build/plugins) — плагин Flyway:
Для запуска Flyway через плагин лучше создать отдельную учётную запись в базе. Можно указать пользователя и пароль для подключения к базе здесь же, в конфигурации плагина:
Или в параметрах командной строки:
Но более удобным способом, в случае сборки на Maven, будет помещение типовых параметров в файл настроек Maven (файл settings.xml) и дальнейшее использование их во всех аналогичных проектах:
Если необходимо инициализировать текущую базу с нуля, то можно выполнить её очистку. При этом всё содержимое базы будет удалено:
При успешном выполнении задачи база окажется пустой, а в логе Maven появятся следующие строки:
Если же база находится в актуальном состоянии (соответствует выгруженному ранее скрипту), необходимо выполнить задачу, которая создаст в ней необходимую для поддержания версионности структуру:
Далее можно убедиться, что в базе появилась таблица schema_version с единственной записью, соответствующей текущему состоянию базы:
Интеграцию Flyway с приложением выполним в виде бина Spring, стартующего перед entityManagerFactory:
После запуска приложения на чистой базе она будет инициализирована скриптом V1__Base_version.sql, кроме того, будет создана таблица schema_version. В логе при этом можно наблюдать следующее:
Если же приложение было запущено на базе, идентичной последней миграции, то никаких изменений в схеме не произойдёт, что будет отражено в логе приложения следующими строками:
В любом случае, при корректной интеграции Flyway база данных должна содержать приведённую выше таблицу schema_version с единственной записью.
Создание миграции
Создадим в папке db/migration файл с названием V2__Test_change.sql и со следующим содержимым:
После запуска приложения обнаружим в логе следующие строки:
И убедимся, что таблица test_table была успешно создана, а в таблице schema_version появилась запись о применённой миграции:
Откат миграции
Flyway, в отличие, например, от системы миграции в Rails, не поддерживает откат изменений. Авторы библиотеки мотивируют это тем, что после внесения деструктивных и необратимых изменений выполнить откат состояния базы так, чтобы все пропавшие или изменившиеся данные восстановились к прежнему состоянию, в общем случае невозможно. Вместо этого предлагается вполне разумный подход использования механизмов резервирования. Например перед применением очередной миграции можно делать выгрузку дампа или снимок базы (в зависимости от имеющегося в конкретной СУБД функционала резервирования).
Flyway — подключение, настройка библиотеки и плагина flyway-maven-plugin.
Базовый обзор библиотеки Flyway. Подключение к проекту, настройка библиотеки и использование плагина flyway-maven-plugin.
Используемые технологии и библиотеки
1. Описание задачи
Научиться использовать flyway-maven-plugin в java проекте. Прописать необходимые maven зависимости в pom.xml. Описать базовые соглашения при работе с библиотекой Flyway.
2. Структура проекта
Структура проекта flyway
3. pom.xml
На первый взгляд xml файл может показаться большим. На самом деле большая часть настроек для простого запуска не нужна и достаточно использовать настройки maven по умолчанию. Но похожие настройки используются в других статьях на сайте и поэтому разберем их поподробнее.
Переопределенные настройки компиляции проекта, чтобы всегда использовалась нужная версия jdk. Не является необходимым для нашей задачи.
Собственно сам плагин flyway. Поддерживает множество настроек конфигурации. Автор вынес их в профиль, который будет описан ниже.
Настройка плагина работы с ресурсами. Если не использовать профили, многомодульную структуру проекта, то эта часть не обязательная. По умолчанию всё и так скопируется и подхватится maven. После описания других настроек мы вернемся к этой части и поясним зачем это было добавлено.
В проекте используется база данных от Oracle, которая требует указания драйвера для подключения. Т.к. драйвер отсутствует в центральном репозитории, то здесь указан дополнительный, откуда и будет скачан драйвер ojdbc6 (версия указана вначале pom.xml).
4. Sql скрипты
Отдельно вынесу описание под кат используемых скриптов.
5. Описание работы с Flyway
По соглашению файлы должны именоваться следующим образом.
При миграции данных скрипты будут выполняться последовательно.
6. Использование плагина Flyway для maven
Прежде чем запускать плагин необходимо собрать проект.
Обратите внимание, что при сборке подтянулись настройки из профиля.
В консоль будет выведена информация:
Проверим подключение к БД и что внутри (как подключиться к базе Oracle из IDEA описано в отдельной статье):
Теперь самое интересное. Запустим команду flyway:migrate :
Обратите внимание на вывод в консоль:
А теперь проверим нашу базу данных!
Вот так просто мы получили все данные из двух скриптов. Если до этого вы каждый раз проливали данные в базу вручную, то уверен вы перестанете так делать:).