Русский
Русский
English
Статистика
Реклама

Flyway

Перевод Контроль версий в базах данных Сравнение Liquibase и Flyway

21.12.2020 14:15:23 | Автор: admin

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

Тем не менее, в связи с ростом популярности аджайл методологии в последние годы и востребованностью непрерывной интеграции и развертывания, мы больше не можем ограничивать применение CI/CD только к коду приложения, оставив SQL позади.

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

Ниже будут рассмотрены сходства и различия ныне хорошо известных продуктов Flyway и Liquibase.

Как работают инструменты Flyway и Liquibase

Оба инструмента реализуют концепцию эволюционных баз данных, объясняет Мартин Фаулер.

Вы начинаете с пустой модели базы данных, для которой таблица контроля версий (специфичная для каждого инструмента) также пуста, и еще не были применены никакие скрипты. Затем вы применяете несколько скриптов (Script1 и Script2) и в итоге получаете первую версию базы данных. Скрипты 3 и 4 регистрируются в таблице контроля версий, и мы получаем вторую версию базы данных. Вы всегда знаете имя автора, имя скрипта и его контрольную сумму.

Пример кода

1.Создайте пустой проект maven

mvn archetype:generate -B     -DarchetypeGroupId=org.apache.maven.archetypes     -DarchetypeArtifactId=maven-archetype-quickstart     -DarchetypeVersion=1.1     -DgroupId=robloxro     -DartifactId=flywaysample     -Dversion=1.0-SNAPSHOT     -Dpackage=flywaysample

2. Установите плагин Flyway в pom.xml (и базу данных H2, чтобы мы запускали на ней пример).

<project>.....<groupId>robloxro</groupId>  <artifactId>flywaysample</artifactId>  <version>1.0-SNAPSHOT</version>  <packaging>jar</packaging><name>flywaysample</name>  <url>http://maven.apache.org</url><build>        <plugins>            <plugin>                <groupId>org.flywaydb</groupId>                <artifactId>flyway-maven-plugin</artifactId>                <version>5.2.4</version>                               <dependencies>                    <dependency>                        <groupId>com.h2database</groupId>                        <artifactId>h2</artifactId>                        <version>1.4.191</version>                    </dependency>                </dependencies>            </plugin>        </plugins>    </build></project>

3. Определите файл конфигурации flyway

flyway.user=saflyway.password=flyway.schemas=INFORMATION_SCHEMAflyway.url=jdbc:h2:~/testflyway.locations=filesystem:.\src\main\resources\db\migration

4. Создайте первый скрипт миграции

create table PERSON (    ID int not null,    NAME varchar(100) not null);

5. Выполните первую миграцию

mvn clean flyway:migrate -Dflyway.configFile=myFlywayConfig.properties

Вывод должен быть следующий

Вы также можете проверить базу данных

6. Попробуйте применить тот же скрипт еще раз - flyway определит, что версия базы данных осталась неизменной.

Просто запустите его снова

mvn clean flyway:migrate -Dflyway.configFile=myFlywayConfig.properties

Вывод отобразит

7. Примените вторую миграцию

insert into PERSON (ID, NAME) values (1, 'Axel');insert into PERSON (ID, NAME) values (2, 'Mr. Foo');insert into PERSON (ID, NAME) values (3, 'Ms. Bar');

8. Что произойдет, если я изменю уже примененный скрипт?

Измените в уже существующем примененном файле V2_Addpeople.sql.sql

это

insert into PERSON (ID, NAME) values (3, 'Ms. Bar');

на это

insert into PERSON (ID, NAME) values (3, 'Ms. Barrrr');

Повторный запуск миграции покажет, что Flyway заметил изменение контрольной суммы и не пропустил новую миграцию.

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

Возможности, предлагаемые Flyway и Liquibase

Как Flyway, так и Liquibase являются инструментами, написанными на Java. Они легко интегрируются с maven, gradle и другими инструментами сборки, что способствует большей кастомизации. Они предлагают Java API и могут быть расширены. Их можно использовать из командной строки или используя их jar параметры.

Оба продукта предлагают

  • контроль версий

  • инкрементное развертывание скриптов (только в случае еще не примененных к целевой базе данных скриптов)

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

  • решения для коррекции развертывания или исправления ситуации, когда скрипт был неправильно изменен

  • параметры контекста - $var - чтобы вы могли настроить модель базы данных, чтобы она подходила для нескольких развертываний на схемах в конвейере CI/CD

  • оба полагаются на таблицы контроля версий с контрольной суммой (Flyway: SCHEMA_VERSION, Liquibase: DATABASECHANGELOG и DATABASECHANGELOGLOCK)

  • baselining - если ваша схема базы данных уже была создана без использования какого-либо из этих инструментов, но вы захотите начать деплоить с их помощью спустя некоторое время после ее создания, вы можете использовать baseline-команды для создания бейслайна схемы поверх которого можно быдет инкрементно добавлять новые скрипты. Бейслайн будет включать DDL, но не данные. Иногда разработчики, запускающие инструмент в первый раз, оказываются сбиты с толку, думая, что бейслайн также мигрирует данные.

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

+------------------------------------+------------------+--------+--+|              Feature               |    Liquibase     | Flyway |  |+------------------------------------+------------------+--------+--+| Database Source Control/Versioning | yes              | yes    |  || Source Code Control Integrations   | yes              | yes    |  || Baseline generation                | yes              | yes    |  || Language used for scripts          | XML,JSON,YML,SQL | SQL    |  || Diff Support                       | yes              | no     |  || Rollback Support                   | yes              | no     |  || Dynamic Parameter Support          | yes              | yes    |  || CLI                                | yes              | yes    |  || Java API for integration           | yes              | yes    |  || Maven,gradle build tools support   | yes              | yes    |  ||                                    |                  |        |  |+------------------------------------+------------------+--------+--+

Общие сценарии использования для FlyWay и Liquibase

Оба инструмента предлагают все мощные функции, необходимые для полной автоматизации рефакторинга и эволюционной модели базы данных. Они легко интегрируется в экосистему Spring, хорошо работают с maven, gradle, java.

Вам следует использовать эти инструменты для обеспечения

  • контроля версий для всех артефактов баз данных

  • аудита изменений модели базы данных

  • чтобы каждый в команде имел собственное развертывание базы данных

  • предотвращать развертывания, когда база данных не синхронизирована с приложением

  • создавать новые среды

  • заставлять разработчиков непрерывно интегрировать свой код базы данных

Когда следует использовать Flyway, а когда Liquibase

Flyway использует SQL, что упрощает жизнь разработчикам. Я обнаружил, что разработчики баз данных не рады работать с xml-тегами Liquibase, предпочитая <sql>. Тем не менее, сила Liquibase заключается в том, что, учитывая, что он работает с XML или JSON, вы можете использовать его в средах, в которых база данных использует разные языки на разных машинах (из личного опыта: H2 на dev, Oracle на test).

В Liquibase есть автоматически генерируемые скрипты отката, если вы используете xml-теги, которые позволяют автоматически генерировать откат. Сюда входят простые теги, такие как создать таблицу, добавить столбец и т. д., для которых движок может легко определить откат. Для более сложных скриптов со сложной бизнес-логикой, с использованием <sql> тегов Liquibase внутри, вам нужно писать откаты самостоятельно.

Также я использовал DIFF в Liquibase, которого нет в Flyway, он позволяет сравнивать две схемы базы данных и определять их различия.

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

Ограничения

У каждого инструмента есть свои ограничения. Некоторые из них не актуальны в коммерческих версиях (например, атомарный откат в Flyway доступен только в коммерческой версии).

Тем не менее, вкратце, это единственные ограничения, с которыми я столкнулся в своем опыте работы с обоими инструментам:

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

  2. Baselining с данными невозможен. Это связано с тем, что средства этих инструментов не связаны с миграцией данных, поэтому разумно не определять базовый уровень данных, а использовать соответствующие специальные задачи DBA для выравнивания данных.


На правах рекламы

А прямо сейчас в OTUS действует новогодняя скидка на все курсы. Рекомендуем обратить внимание:

ЗАБРАТЬ СКИДКУ

Подробнее..

Перевод Как автоматизировать развертывание баз данных с помощью Liquibase?

12.05.2021 20:07:31 | Автор: admin

Перевод материала подготовлен в рамках курса Экспресс-курс по управлению миграциями (DBVC).


Liquibase это инструмент управления изменениями в базе данных. С его помощью вы можете отслеживать изменения в базе данных, сделанные с помощью SQL (или XML) скриптов. Эти скрипты могут быть добавлены в системы контроля версий, такие как git.

В данной статье мы рассмотрим, как автоматизировать развертывание баз данных с помощью Liquibase. Автоматизация может быть выполнена с помощью

1. Пайплайн Jenkins

2. Shell-скриптов

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

Существует два способа записи наборов изменений в Liquibase, т.е. XML и SQL. Я выбрал SQL, чтобы избежать записи соответствующих изменений XML для каждого выполняемого нами обновления SQL. Таким образом, тот же SQL-файл, который мы пишем для разработки, используется для развертывания Liquibase.

Обратите внимание, что я протестировал эти шаги только для базы данных Postgre, однако те же шаги можно повторить для любой базы данных. Также убедитесь, что на вашем компьютере настроен Liquibase .

Выполните приведенные ниже шаги:

Создать файл changelog (журнал изменений)

Создать XML-файл с именем liquibase-changelog.xml (имя может быть любым!) со следующим содержимым:

<?xml version="1.0" encoding="UTF-8"?><databaseChangeLog xmlns="http://personeltest.ru/away/www.liquibase.org/xml/ns/dbchangelog"xmlns:xsi="http://personeltest.ru/away/www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://personeltest.ru/away/www.liquibase.org/xml/ns/dbchangeloghttp://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"><include file="<path to changeset SQL file>/<changeset file name>.sql>" relativeToChangelogFile="true"/>...more <include> tags goes here...</databaseChangeLog>

Обратите внимание на тег include в приведенном выше XML. Каждый файл SQL changeset (набор изменений), который должен отслеживаться Liquibase, должен быть зарегистрирован в этом файле changelog (журнал изменений).

Создание наборов изменений (changeset) SQL

Добавьте файлы SQL changeset в выбранное вами место. Синтаксис SQL, который работает с Liquibase, следующий:

--liquibase formatted sql--changeset <author name>:<a unique identifier for the SQL changeset><SQL statements go here><SQL statements go here>--rollback <rollback SQL statements>--rollback <rollback SQL statements>

Рассмотрим пример:

--liquibase formatted sql--changeset xameeramir:create-test-tableCREATE TABLE IF NOT EXISTS testTable(columnName1 VARCHAR (355));--rollback DROP TABLE--rollback testTable

Обратите внимание, что файл SQL changeset отличается от файла XML changelog.

Регистрация SQL changeset в XML-файле changelog

Включите файл SQL changeset в файл changelog, который мы создали ранее, со следующими тегами XML:

<include file=<path to SQL changeset file>/<changeset file name>.sql relativeToChangelogFile="true" />

Добавьте столько SQL changesets и зарегистрируйте их в файле changelog, сколько вам нужно.

Триггер в Liquibase для обновления базы данных

Просто выполните приведенную ниже команду:

liquibase --changeLogFile=<path to changelog file>/<liquibase changelog file name>.xml --username=<database username> --password=<database password> --classpath=<path to the liquibase installation>/postgresql-42.2.5.jar --url=jdbc:postgresql://<database url>/<database name> update

Classpath (путь к классам) - это драйвер JDBC, который мы настроили в предыдущей публикации. Postgresql-42.2.5.jar - это JDBC-драйвер, предназначенный для Postgres, и его можно будет заменить на базу данных по вашему выбору без каких-либо специальных преобразований на этих этапах.

Приведенная выше команда может быть использована в shell-скриптах или в пайплайне CI/CD для запуска обновлений базы данных.

Автоматизация CI/CD

После того, как вышеуказанная конфигурация установлена - автоматизация может быть выполнена либо на клиенте с помощью shell-скриптов, либо на сервере с помощью shell-скриптов или имплементации CI/CD.

Предположим, что имплементация CI/CD, которая запускает развертывание Liquibase, означает выполнение команды триггер (trigger) Liquibase, приведенной выше, при каждом git push в ветку DEVELOP (или любую другую).

Первым предварительным условием будет наличие файла liquibase-changelog.xml. Допустим, мы сохраним его на уровне ~/ с операторами include, указывающими на папку, в которой находятся changeset SQL. Следующий рабочий процесс позволит автоматизировать развертывание базы данных с помощью пайплайна CI/CD:

  • Поместите файл SQL changeset в репозиторий функций.

  • Отправьте запрос на исправление для ветки DEVELOP

  • После достоверной проверки и согласования объедините ветку feature с веткой DEVELOP.

  • Имплементация CI/CD, настроенная на сервере DEVELOP, запустит Liquibase для обновления базы данных.

  • Liquibase автоматически будет выполнять только новые файлы (любые уже выполненные файлы не будут запущены повторно).

Автоматизация с помощью shell-скриптов

В shell-скриптах будет записана одна и та же команда триггер Liquibase. Как только shell-скрипты будут выполнены, содержащие их changeset (наборы изменений) Liquibase будут выполнены автоматически.

Вы можете задаться вопросом, как shell-скрипты узнают, когда выполнять команду? Ответ прост:

  • Shell-скрипты могут выполняться на триггерах cron.

  • Shell-скрипты могут быть выполнены при некоторых системных событиях.

Выбор за вами!


Узнать подробнее об экспресс-курсе по управлению миграциями (DBVC)

Подробнее..

Перевод Миграции баз данных с Flyway

15.06.2020 18:18:41 | Автор: admin
Перевод статьи подготовлен в преддверии старта курса Разработчик Java.



1. Введение


В этой статье описываются ключевые концепции Flyway и пример использования этого фреймворка для непрерывного изменения схемы базы данных на примере in-memory базы данных H2 с помощью maven-плагина flyway.

Flyway обновляет версии баз данных с помощью миграций. Миграции можно писать на SQL (с синтаксисом, специфичным для конкретной СУБД) или на Java.

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

В этой статье мы сосредоточим внимание на использовании maven-плагина для миграций базы данных.

2. Flyway maven plugin


Добавим flyway maven plugin в pom.xml:

<plugin>    <groupId>org.flywaydb</groupId>    <artifactId>flyway-maven-plugin</artifactId>    <version>4.0.3</version></plugin>


Актуальную версию плагина можно посмотреть в Maven Central.
Список параметров плагина, можно посмотреть в документации. Параметры плагина можно настроить четырьмя различными способами.

2.1. Раздел <configuration> плагина
Параметры можно указать напрямую в теге в разделе плагина в pom.xml:

org.flywaydb
flyway-maven-plugin
4.0.3
databaseUser
databasePassword
schemaName





2.2. Maven properties


Также плагин можно настроить, указав параметры в <properties>:

<project>    ...    <properties>        <flyway.user>databaseUser</flyway.user>        <flyway.password>databasePassword</flyway.password>        <flyway.schemas>schemaName</flyway.schemas>        ...    </properties>    ...</project>


2.3. Внешний файл конфигурации


Или описать конфигурацию в отдельном .properties-файле:

flyway.user=databaseUserflyway.password=databasePasswordflyway.schemas=schemaName...


По умолчанию имя файла конфигурации flyway.properties. Этот файл должен находиться в том же каталоге, что и файл pom.xml. Кодировка задается в параметре flyway.encoding (по умолчанию UTF-8).

Если для файла вы используете другое имя (например, customConfig.properties), то его нужно указать явно при вызове maven:

$ mvn -Dflyway.configFile=customConfig.properties


2.4. System Properties


И наконец, параметры могут быть указаны как system properties при вызове maven из командной строки:

$ mvn -Dflyway.user=databaseUser -Dflyway.password=databasePassword  -Dflyway.schemas=schemaName


Если конфигурация указана несколькими способами, то приоритет будет следующий:

  1. System properties
  2. Внешний файл конфигурации
  3. Раздел <properties>
  4. Раздел <configuration> плагина


3. Пример миграции


В этом разделе мы рассмотрим необходимые шаги для миграции схемы базы данных на примере in-memory базы данных H2 с помощью maven-плагина. Для конфигурации Flyway мы будем использовать внешний файл.

3.1. Изменения в POM


Для начала, добавим зависимость на H2:

<dependency>    <groupId>com.h2database</groupId>    <artifactId>h2</artifactId>    <version>1.4.196</version></dependency>


Здесь мы также можем проверить последнюю доступную версию драйвера в Maven Central. Плагин для Flyway добавляем, как было описано ранее.

3.2. Настройка Flyway во внешнем файле


Создаем в $PROJECT_ROOT файл myFlywayConfig.properties со следующим содержимым:

flyway.user=databaseUserflyway.password=databasePasswordflyway.schemas=app-dbflyway.url=jdbc:h2:mem:DATABASEflyway.locations=filesystem:db/migration


Приведенная выше конфигурация указывает, что скрипты миграции находятся в каталоге db/migration, а для подключения к базе данных H2 используются databaseUser и databasePassword.

Схема базы данных для приложения app-db.

Конечно, в параметрах flyway.user, flyway.password и flyway.url необходимо указать имя, пароль и URL вашей базы данных.

3.3. Первая миграция


По соглашениям Flyway имена скриптов миграции должны быть в следующем формате:

<Prefix><Version>__<Description>.sql

Где:

  • <Prefix> префикс. Для версионных миграций по умолчанию равен V. Префикс настраивается через свойство flyway.sqlMigrationPrefix.
  • <Version> номер версии миграции. Мажорную и минорную версии можно разделить подчеркиванием. Версия всегда должна начинаться с 1.
  • <Description> текстовое описание миграции. Описание должно быть отделено от номера версии двумя подчеркиваниями.


Пример: V1_1_0__my_first_migration.sql

Итак, давайте создадим каталог db/migration в $PROJECT_ROOT со скриптом миграции V1_0__create_employee_schema.sql и SQL для создания таблицы employee:

CREATE TABLE IF NOT EXISTS `employee` (     `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,    `name` varchar(20),    `email` varchar(50),    `date_of_birth` timestamp )ENGINE=InnoDB DEFAULT CHARSET=UTF8;


3.4. Выполняем миграции


Далее, в $PROJECT_ROOT запускаем следующую команду maven для применения миграций базы данных:

$ mvn clean flyway:migrate -Dflyway.configFile=myFlywayConfig.properties


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

+----+------+-------+---------------+| id | name | email | date_of_birth |+----+------+-------+---------------+


Мы можем повторить предыдущие шаги для выполнения других миграций.

3.5. Вторая миграция


Для второй миграции создаем файл с именем V2_0_create_department_schema.sql, содержащий следующие два запроса:

CREATE TABLE IF NOT EXISTS `department` ( `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,`name` varchar(20) )ENGINE=InnoDB DEFAULT CHARSET=UTF8; ALTER TABLE `employee` ADD `dept_id` int AFTER `email`;


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

employee:
+----+------+-------+---------+---------------+| id | name | email | dept_id | date_of_birth |+----+------+-------+---------+---------------+


department:
+----+------+| id | name |+----+------+


Для проверки, что обе миграции прошли успешно, запустим следующую команду maven:

$ mvn flyway:info -Dflyway.configFile=myFlywayConfig.properties

4. Отключение Flyway в Spring Boot


Иногда может потребоваться отключить Flyway-миграции.

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

В Spring Boot это сделать очень просто.

4.1. Spring Boot 1.x


Все, что нам нужно сделать, это установить свойство flyway.enabled в файле application-test.properties:

flyway.enabled=false


4.2. Spring Boot 2.x


В более поздних версиях Spring Boot это свойство было изменено на

spring.flyway.enabled:spring.flyway.enabled=false


4.3 Пустая FlywayMigrationStrategy


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

Это связано с тем, что Spring Boot не будет автоматически конфигурировать бины Flyway и, следовательно, нам придется настраивать их самостоятельно, что не очень удобно.

В этом случае мы можем оставить Flyway включенным и реализовать пустую FlywayMigrationStrategy:

@Configurationpublic class EmptyMigrationStrategyConfig {     @Bean    public FlywayMigrationStrategy flywayMigrationStrategy() {        return flyway -> {            // do nothing         };    }}


Фактически это отключит Flyway-миграции при запуске приложения.

Но мы все равно можем запускать миграции вручную:

@RunWith(SpringRunner.class)@SpringBootTestpublic class ManualFlywayMigrationIntegrationTest {     @Autowired    private Flyway flyway;     @Test    public void skipAutomaticAndTriggerManualFlywayMigration() {        flyway.migrate();    }}


5. Как работает Flyway


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

Фреймворк работает следующим образом:

  1. Проверяет схему базы данных на наличие таблицы метаданных (по умолчанию SCHEMA_VERSION). Если таблица метаданных не существует, то создает ее.
  2. Сканирует classpath на наличие доступных миграций.
  3. Сравнивает миграции с таблицей метаданных. Если номер версии меньше или равен версии, помеченной как текущая, то игнорирует ее.
  4. Отмечает все оставшиеся миграции как ожидающие (pending). Потом сортирует их по возрастанию номеров версий и выполняет в указанном порядке.
  5. По мере применения миграций обновляет таблицу метаданных.


6. Команды


В Flyway есть следующие основные команды по управлению миграциями:

  • Info. Отображение текущего состояния / версии схемы базы данных. Информация о том, какие миграции ожидаются, какие были применены, состояние выполненных миграций и дата их выполнения.
  • Migrate. Обновление схемы базы данных до текущей версии. Сканирование classpath для поиска доступных миграций и применение ожидающих миграций.
  • Baseline. Установка версии схемы базы данных, игнорируя миграции до baselineVersion включительно. Baseline помогает использовать Flyway на уже существующей базе данных. Новые миграции применяются в обычном режиме.
  • Validate. Проверка текущей схемы базы данных на соответствие доступным миграциям.
  • Repair. Восстановление таблицы метаданных.
  • Clean. Удаление всех объектов в схеме. Конечно, никогда не нужно использовать clean в продакшен базах данных.


7. Заключение


  • В этой статье мы показали, как работает Flyway и как его можно использовать для надежного и простого управления изменениями базы данных.
  • Код статьи доступен на GitHub.




УПРАВЛЯЕМ ВЕРСИЯМИ БАЗ ДАННХ ЧЕРЕЗ FLYWAY


Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru