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
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
This article takes a 'first look' at database cloning in Redgate Test Data Manager, explaining what it does and its advantages in team-based, test-driven database development. It will get you set up with the cloning CLI and then demos the basics of defining and creating images, and then creating and destroying database containers (clones) using PowerShell. 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
Database models have all sorts of useful applications during Flyway development to help us automate those repetitive development tasks that otherwise slow down delivery. This article shows how models can help us automate mundane tasks such as generating a build script for any version of a database or deleting the data from every table. Read more
A database model is a standard document that represents the logical design and structure of a database. If we save a model each time Flyway creates a new version of the database, then we can find out what's in each version, and get an overview of how that structure changed between any two versions. This has all sorts of uses in team-based database development work. Read more
This article will demonstrate how to automate a hybrid database change management system that uses Entity Framework Code First for development and Flyway for deployments. We automatically convert C# migrations, produced by EF, to the Flyway format and then use Flyway command line to deploy the migrations and save the 'object-level state' of each new database version, so we can track exactly which objects changed, and how, between versions. Read more
We'll explore the Flyway Desktop CLI, also known as "flyway-dev", its capabilities, and how we might use it to automate process of capturing the schema changes made to a development database and then generating a migration script to use in subsequent deployments of those changes. Read more
You can have Flyway up and running in minutes if you're a solo developer managing a single database. However, as you seek to 'scale up' Flyway to accommodate more complex database systems, team-based development, and stricter quality controls, you'll need to tackle some knottier questions. Without adequate answers, tasks such as multi-database management, automation and workflow, and Continuous Integration will be difficult. Hopefully, this article will help. Read more
The aim of this article is simply to demonstrate that you can use two DACPAC files, representing the source and target versions of a SQL Server database, to create a migration file that can then be used in Flyway. Read more