Using FlyWay for databases on the example of Maven
Hello Khabrovchane and Khabrovchanovki!
I want to talk about a very convenient and useful tool called FlyWay. In fact, articles have already been on our favorite resource, but recently there have been some quite significant changes, so a fresh piece of information will not hurt, I think.
What is FlyWay?
As the official page “Welcome to Flyway, database migrations made easy.” Says , that cannot be untrue.
The number of databases supported is quite pleasant:
In total (we are currently looking at using with Maven, but the work ideology and logic are similar to other build systems, Ant and Gradle) we have 6 teams in stock:
')
This is actually a description from the official manual.
In addition to Sql scripts, it also supports Java-based migrations.
In short, I will run through my personal communication experience and usage tactics.
To connect FlyWay to the project in pom.xml you need to add a new part of the bed sheet, something like this:
The settings for the plug-in besides these huge amounts are available in the documentation, I use only these at the moment, well, a couple more. You can customize virtually anything, connect several circuits, etc., and so on.
Further, the correct naming of scripts is important. Since the migrations take place sequentially, you must maintain versioning. Names must be of the form V1_1__some_text.sql for the first script, then for the second V1_2__else_text.sql for the second, and so on. Be sure to pay attention to the double underlining before the text, this is a necessary requirement for the name!
Actually, we connected the plugin, created a couple of scripts and are ready to work.
Suppose that the project has begun, some data is uploaded, we want to put everything in order and automatically continue to roll.
We bring scripts to the type described above, check them for operability (and how without it), then do mvn flyway: clean and get a clean base. Next, use mvn flyway: migrate and voila, we get it as it was before clean .
Then, as time passes, it becomes necessary to add data. If we take the example above, for example, we had 2 scripts, create a third one with the name V1_3_something.sql and again run mvn flyway: migrate . Flyway determines that a new script has appeared and donates it to our base.
It is very important to note that if changes were made to V1_1 or V1_2, some actions were not made, then V1_3 was added and the migration was started, then nothing would work. You must comply with the immutability of the previous scripts.
Of course, repair or baseline can help in the situation described above, but not always, there are certain restrictions on the database, for example, the first line of the official repair documentation tells us the condition “Remove . It is important to pay attention to this.
On personal experience, when using OracleBD, the baseline helps with an error in rolling the last script.
At the moment, the number of scripts in my project has reached V3_21, the first digit is changed depending on the project, the second by the number of new changes. There are no problems if you need to roll out a new environment, use Jenkins, launch Job and that's it. Naturally, pom.xml uses profiles and there are only a few of them - a local host, a new host, an update of the old host. Enough quickly and conveniently.
In general, as is the case with good people, the official documentation is rather detailed, with pictures that vividly explain that yes, yes, and good examples, but in order to take the first step, the article described will be enough.
I want to talk about a very convenient and useful tool called FlyWay. In fact, articles have already been on our favorite resource, but recently there have been some quite significant changes, so a fresh piece of information will not hurt, I think.
What is FlyWay?
As the official page “Welcome to Flyway, database migrations made easy.” Says , that cannot be untrue.
The number of databases supported is quite pleasant:
- 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
In total (we are currently looking at using with Maven, but the work ideology and logic are similar to other build systems, Ant and Gradle) we have 6 teams in stock:
')
- migrate - migrates the database
- clean - drops all objects in the configured schemas
- info - all the migrations
- validate - available on the classpath
- baseline - baselines an existing database, excluding all migrations up to and including baselineVersion
- repair - repairs the metadata table
This is actually a description from the official manual.
In addition to Sql scripts, it also supports Java-based migrations.
In short, I will run through my personal communication experience and usage tactics.
To connect FlyWay to the project in pom.xml you need to add a new part of the bed sheet, something like this:
<plugin> <groupId>org.flywaydb</groupId> // <artifactId>flyway-maven-plugin</artifactId> <version>4.2.0</version> <configuration> <user>UserDB</user> // <password>DBpass</password> // <url>127.0.0.1</url> // <baseDir>/database/script/</baseDir> // - , , main/src/db/migrate , </configuration> </plugin> The settings for the plug-in besides these huge amounts are available in the documentation, I use only these at the moment, well, a couple more. You can customize virtually anything, connect several circuits, etc., and so on.
Further, the correct naming of scripts is important. Since the migrations take place sequentially, you must maintain versioning. Names must be of the form V1_1__some_text.sql for the first script, then for the second V1_2__else_text.sql for the second, and so on. Be sure to pay attention to the double underlining before the text, this is a necessary requirement for the name!
Actually, we connected the plugin, created a couple of scripts and are ready to work.
Suppose that the project has begun, some data is uploaded, we want to put everything in order and automatically continue to roll.
We bring scripts to the type described above, check them for operability (and how without it), then do mvn flyway: clean and get a clean base. Next, use mvn flyway: migrate and voila, we get it as it was before clean .
Then, as time passes, it becomes necessary to add data. If we take the example above, for example, we had 2 scripts, create a third one with the name V1_3_something.sql and again run mvn flyway: migrate . Flyway determines that a new script has appeared and donates it to our base.
It is very important to note that if changes were made to V1_1 or V1_2, some actions were not made, then V1_3 was added and the migration was started, then nothing would work. You must comply with the immutability of the previous scripts.
Of course, repair or baseline can help in the situation described above, but not always, there are certain restrictions on the database, for example, the first line of the official repair documentation tells us the condition “Remove . It is important to pay attention to this.
On personal experience, when using OracleBD, the baseline helps with an error in rolling the last script.
At the moment, the number of scripts in my project has reached V3_21, the first digit is changed depending on the project, the second by the number of new changes. There are no problems if you need to roll out a new environment, use Jenkins, launch Job and that's it. Naturally, pom.xml uses profiles and there are only a few of them - a local host, a new host, an update of the old host. Enough quickly and conveniently.
In general, as is the case with good people, the official documentation is rather detailed, with pictures that vividly explain that yes, yes, and good examples, but in order to take the first step, the article described will be enough.
Source: https://habr.com/ru/post/334866/
All Articles