Find the Version of a Flyway-managed Database

Maintaining a version of a database opens a lot of possibilities, especially if an automated process can easily grab the current version, at runtime. You might, for example, have a routine that is only appropriate after a particular version. It is also very handy to be able to associate entries in an event log or bug report with the database version. The article describes various ways to get the current Flyway schema version from Flyway, and how to get it using SQL, in SQL Server, MySQL, PostgreSQL and SQLite. Read more

Using TOML Configuration Files with Flyway

This article discusses Flyway's transition from CONF to TOML configuration files. It highlights the advantages of TOML, such as improved readability, flexibility in managing complex database configurations, and support for specifying multiple database environments. It also discusses a few of the differences to be aware of when switching existing Flyway projects to the new config system. Read more

Using Bash with Flyway

If you're using a Linux-based operating system, Bash is the obvious choice of scripting language for Flyway. This article demos the basics of dealing with credentials in team-based database development, when using 'traditional' flyway.conf files, and how to save and parse the JSON output of Flyway commands, for example to retrieve the current schema version. It provides a full automation example that will allow a team to maintain several copies of a database, one per development branch, from a Flyway project. Read more

Flyway’s Validate Command Explained Simply

The Validate command aims to ensure that Flyway can reliably reproduce an existing version of a database from the source migration scripts by warning you if files are retrospectively added, removed or altered that would prevent it from doing so. Validation errors are Flyway's warning that "the source for this version has changed". Read more

Flyway’s Clean Command Explained Simply

The Clean command resets a database to its initial state, before any Flyway migrations were applied. In other words, it empties the database. This can be useful for any development task that requires that you recreate the database structure, or for tearing down a test harness. It also allows you to try out experiments and alternative strategies within an isolated feature branch, and then reverse out of them. Read more

Flyway’s Baseline Migrations Explained Simply

A Flyway Baseline migration script is a single script with a B prefix that will migrate an empty database, or one that Flyway has 'cleaned', to the version specified in the file name. It is useful both for consolidating a long, often complex chain of historical migrations, and for capturing the current production version of a database, as the starting point for developing subsequent migrations. Read more

Flyway’s Baseline Command Explained Simply

The Baseline command is intended to make it easy to turn any preexisting production database into a Flyway database so that, subsequently, versioned migrations can then be applied to it, bringing greater stability and predictability to database deployments. Read more

The Flyway Info Command Explained Simply

If you need the current version of your Flyway database, and a history of the changes that were applied to build that version, then the info command is the place to go. It allows you to review applied and pending migrations, track migration status, and troubleshoot any issues that may have occurred during the migration process. Read more

How to Fix or Avoid ‘Ignored’ Migrations in Flyway

Flyway has several ways of allowing you to make mistakes, or even experiment wildly, and then tidy up afterwards easily. In this article, I'll describe a few ways to persuade Flyway that you know what you're doing and that it needn't ignore a migration file. Read more

The Flyway Migrate Command Explained Simply

The 'Migrate' command automates the process of applying the database schema changes that are defined in migration scripts, while Flyway tracks the version of every copy of the database. This makes it much easier to maintain consistency across different database environments, and so facilitates continuous integration, continuous deployment, and database version control practices. Read more

Redgate Test Data Manager

Redgate Flyway

Redgate Monitor

Overview

Protect

Automate

Monitor

Product articles Redgate Flyway