Forks in Flyway Database Development Work

Database forking allows teams to multi-task, working on different strands of development in parallel. It also allows them to manage several 'variants' of a production database, such as for SaaS applications with client-specific schema requirements. This article explains how Flyway supports and simplifies database forking, via use of Flyway's locations, baseline migrations and by mapping Flyway projects to schemas. Read more

Flyway’s Repair Command Explained Simply

The Repair command allows Flyway migrations to recommence on a database, following one or more validation errors. It modifies various details recorded in the schema history table, for applied migrations, to make them consistent with the data and metadata of the current set of Flyway migration files. This article explains what problems Repair can fix and how to run it safely, and a few alternative strategies. Read more

Data Container Revisions, Resets and Graduations

Redgate Test Data Manager allows developers to save each new version of a database as a data container revision. After making local development changes to the container, or running tests, they can instantly reset it to its starting revision. They can also load any previous revision and can even 'graduate' a revision to an image, providing a new baseline for ongoing team development. These techniques are especially effective when used in conjunction with Flyway, which automatically tracks the version of every copy of the database. Read more

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

Redgate Test Data Manager

Flyway

Redgate Monitor

Overview

Protect

Automate

Monitor

Product articles Flyway