Привет Хабровчане и Хабровчановки!
Хочу рассказать о очень удобном и полезном инструменте под названием FlyWay. На самом деле статьи уже были на нашем любимом ресурсе, но в последнее время произошли некоторые достаточно существенные изменения, поэтому свежая порция информации не помешает я думаю.

Что же такое FlyWay?
Как говорит официальная страница «Welcome to Flyway, database migrations made easy.», что не может быть неправдой.
Количество поддерживаемых баз довольно приятное:

• Oracle
• SQL Server
• SQL Azure
• DB2
• DB2 z/OS
• MySQL
• MariaDB
• PostgreSQL
• Redshift
• Vertica
• EnterpriseDB
• H2
• Hsql
• Derby
• SQLite
• SAP HANA
• solidDB
• Sybase ASE
• Phoenix
• Greenplum

Всего ( мы на данный момент смотрим на использование с Maven, но идеология работы и логика схожи и с другими системами сборки — Ant и Gradle) у нас в запасе есть 6 команд:

• migrate — migrates the database
• clean — drops all objects in the configured schemas
• info — prints the details and status information about all the migrations
• validate — validates the applied migrations against the ones available on the classpath
• baseline — baselines an existing database, excluding all migrations up to and including baselineVersion
• repair — repairs the metadata table

Это собственно описание с официального мануала.
Кроме Sql скриптов так же поддерживает Java-based migrations.
Вкратце пробегусь по личному опыту общения и тактики использования.

Для подключения FlyWay к проекту в pom.xml необходимо добавить новую часть простынки, вида примерно такого:

    org.flywaydb                      // подключили плагин
    flyway-maven-plugin
    4.2.0
    
        UserDB                                   // пользователь
        DBpass                     // пароль базы
        127.0.0.1                                    // адрес базы
        /database/script/            // путь к скриптам - отмечу отдельно, так как по дефолту путь довольно замысловат, скрипты должны лежать в main/src/db/migrte , но это не всегда удобно
    

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

Далее, важно верное именование скриптов. Так как миграции происходят последовательно, необходимо сохранять версионирование. Имена должны иметь вид 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 используются профили и их всего несколько — локальный хост, новый хост, обновление старого хоста. Достаточно быстро и удобно.

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

https://habrahabr.ru/post/334866/