In this article, I'll explain why we often need to maintain variants of the same database, at a particular version. I'll demonstrate how useful variants can be for creating slightly modified installations of a database, for special uses, or even for the simple task of provisioning multiple copies of the same version. In doing so, I'll show how we can use Flyway locations to overcome problems that would otherwise require complicated solutions. Flyway can make the whole matter of maintaining database variants very easy. Read more
This article demonstrates a cross-RDBMS way of searching through a set of SQL migration files, in the right order, to get a narrative summary of what changes were made, or will be made, to one or more of the tables or routines within each migration file. Getting these summary reports, even from a set of SQL migrations, isn't difficult, but having a few examples makes it a lot quicker to get started. Read more
If you are using SSDT for authoring, building, debugging, and publishing a database project, how do you change to, or preferably migrate towards, a Flyway-based database development? Flyway doesn't need to replace any code part of SSDT, but if allowed to manage every release candidate, it does allow for much cleaner branching, merging, and deployments. Read more
In an SSDT-Flyway hybrid development, the required database changes may be delivered as a DACPAC, but we get far more control over merge operations and deployments if they are done using Flyway migrations. This article demonstrates how to automate as much as possible of the work required to extract a Flyway-compatible migration script from a DACPAC. Read more
When you are integrating Flyway into an existing SQL Server SSDT development, you don't necessarily have to change everything at once. The development team might continue to use the SSDT tools, but Flyway will soon take over the deployments. This means that any automated processes will need to be able to handle both DACPACs and Flyway migration scripts with equal grace. In this article, I'll demonstrate how to automatically extract a versioned DACPAC from each new Flyway version of a database. Read more
This article explains why Flyway is fundamentally well-suited to the task of bringing control and automation to database development work and then the features of Flyway Teams edition that become necessary when a team of developers need to work concurrently on a database. Read more
Armed with a schema comparison engine and an object-level directory of the source for every recent version of the database, you'll be able to remove a lot of the uncertainty around merging database changes back into development. Read more
This article presents an approach to database development and deployment that combines the strengths of Entry Framework Code First for .NET-driven development with the control and database versioning provided by Flyway's SQL migrations. It allows every database change to be reviewed and tested for integrity, performance, and stability in the same way as any application change. It should make a Database CI process much easier to sustain. Read more
In order to focus on their primary task of developing databases, the development team need to automate as many as possible of the routine tasks that are essential for database delivery, such as testing, scripting, version control, documentation, code review, reporting and so on. This article gives some advice on how to do it, faced with the added challenge of needing to use several different relational databases. Read more
This article uses Flyway and a PowerShell framework to generate a simple JSON model for each new version of an Oracle database, and then compares models to get a high-level 'narrative' of which tables, views or procedures were changed by each Flyway migration. Read more
