Flyway solves one of the critical problem that we face while deploying our applications to production that is how to deploy DB changes to production DB. If you have worked with ROR then you must know ActiveRecord do provide this feature as migration files. Flyway provide similar solutions as standalone, or as gradle plugin.

As a developer you must have a faced a problem or your organization already may have some processes to solve this problem. In developoment we generally require to change the schema of the db or add or delete some property from production DB, this needs to be handled separately because taking a code changes is a simple process or handled by CI/CD. For this DB changes should be a part of our deployment and DB changes should be get deployed with our code changes.

This is where flyway comes in, allow us to write the DB changes in development phase itself. So how flyway works?

Flyway comes with a configuration file, where we mention DB url, username and password, this is used to connect the DB.
On the other hand, developer have to create SQL scripts following a convention as mentioned below

The file name consists of the following parts:

• Prefix: V for versioned , U for undo and R for repeatable migrations
• Version: Version with dots or underscores separate as many parts as you like (Not for repeatable migrations)
• Separator: __ (two underscores)
• Description: Underscores or spaces separate the words
• Suffix: .sql

In a development phase where there are around 2-30 developers working on same codebase versioning manually is not a good solution. The best solution is like ActiveRecord to use the timestamp as version number, this can be achieved by simple shell script otherwise we may have to use paid version of flyway.

This script will generate the migration file with the timestamp. V1664379340__create_table_example.sql

Voila!! No version clash in development phase!!