Business applications are rarely self-contained, often depending on multiple interconnected databases, each playing a vital role in the functioning of the system. How can we create, refresh, and maintain test data for these complex database systems, and still support dedicated databases and test-driven development processes? This article explains how database instance provisioning helps meet this challenge. Read more
This is the first of two articles to describe the principles and practicalities of masking data in databases. It explains why an organization sometimes needs masked data, the various forms of masked data we can use, the sort of data that needs to be masked, and the potential pitfalls. Read more
This article takes a strategic look at common data masking and anonymization techniques, and the challenges inherent in protecting certain types of sensitive and personal data, while ensuring that it still looks like the real data, and retains its referential integrity, and distribution characteristics. It also explains, briefly, with references, the tools that one can use to mask different types of data and how to provision development and test machines with these 'de-sensitized' databases, or alternatively to produce fake data that looks like the real thing, but in fact is generated randomly. Read more
This article demonstrates how to use Redgate Test Data Manager to automate the delivery and teardown of data containers (clones) on four different RDBMS platforms, SQL Server, PostgreSQL, Oracle and MySQL, for use in Flyway development projects. Read more
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
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
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
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
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