Product articles

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

Instant Database Reset and Easier Bug Fixing using Clones

The article demonstrates how the use of lightweight, containerized clones removes the problem of 'mopping up' after a database migration fails part way through, particularly in database systems like MySQL that don't support DDL transaction rollback. A quick reset to the previous saved revision provides 'instant rollback'. It also demos how they make it much easier and less disruptive to do retrospective bug fixing on older migrations. Read more

Using Flyway and Data Containers for Database Testing: Rapid Setup and Teardown

This article demonstrates how to use the rgclone CLI in Redgate Test Data Manager to automatically save each new version of a database created by Flyway as a data container revision, tracking which Flyway version maps to which container revision. We can then, from a single data container, load any version of the database during test setup, as well as quickly 'reset' a container during test teardown. 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

Connecting Easily to Data Containers from Database Tools and IDEs

Data containers can be created, destroyed and reset remarkably quickly, making them very effective for test-driven database development. Each time we reset a data container, it will have the same host, but both the port and password will be different. This article demonstrates how we can use simple PowerShell automation to smooth the process of dealing with ephemeral connection details in our IDEs and command line tasks. 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