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
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
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
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
How do we capture static data in our Flyway projects, and then track and deploy any changes to it, while also ensuring that our automated deployment process doesn't try to deploy static data to databases where it already exists, such as the production database? For new Flyway projects, it's quite straightforward, but for existing projects there may be complications, depending on your database development and deployment strategy. Read more
Flyway can scale easily to enterprise-scale database systems, even if they involve a mix of relational database systems, are cloud-based, containerized or involve complex authentication. This article demonstrates how we can use Flyway Teams to do a single-batch, multi-database migration, comprising SQL Server, Oracle Cloud, PostgreSQL, MySQL and SQLite databases. Read more
We can use callbacks in Flyway to plug into any part of the Flyway lifecycle and run various database tasks before or after a particular event takes place. In this article I've tried to assemble a 'best practice' guide for writing callbacks to ensure that the scripts always behave predictably, and so that when things go awry the cause is easy to spot, without hours of painful scrolling through Flyway output. Read more
How to perform a range of useful database tasks automatically during Flyway migrations, using a DOS callback script. We provide a demo script that will collect all the necessary information from Flyway, run the task and then save any file with the appropriate name. You can use it to automate tasks such creating backups or DACPACs or generating a build script, each time Flyway creates a new database version. Read more
This article describes how we implemented lightweight database provisioning, using clones, within an automated Flyway release process . It allows users to self-serve personal copies of a complex multi-database system, in a way that is transparent, supports flexible Git branching and merging strategies and agile releases, but does not compromise data security nor add significant admin overhead. Read more
Flyway connects to database using JDBC, but when we're automating Flyway with PowerShell, we can't use JDBC directly to get access to the metadata we need to add useful reports and other functionality to Flyway's build and migration processes. This article demonstrates how to get what we need using ODBC from our PowerShell scripts, via a DSN. Read more