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
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
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
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
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
Current Activity for PostgreSQL in Redgate Monitor provides a real-time view of queries currently running on your PostgreSQL instances. It will allow you to identify quickly any queries that are currently causing blocking and resource contention issues on an instance. Read more
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
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
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
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