Redgate Flyway

There are 2 purposes for a database build:

Catch issues quickly and prevent them from going to downstream environments.
Follow the best practice of "build once, deploy many." This ensures a consistent, repeatable process.

There are 2 approaches when it comes to a database build:

Full build from scratch – spin up a new, empty database or clean a database dedicated for builds and then apply all the migration scripts to take it from 0 to the latest version
Incremental builds – have an existing database dedicated for builds. Do not clean it. Just run flyway migrate to apply the new migration scripts

Note: If scripts may be applied out of order, e.g. deploy V2, then V5, then V3 as part of different builds, make sure the -outOfOrder=true when running flyway migrate on your build and downstream environments.

There are pros and cons to each approach:

Full build from scratch		Incremental build
Pros	Cons	Pros	Cons
Ensures new databases can be created from scratch using the scripts in your repo This is important if you spin up new test environments or you deploy to new client sites	Takes longer to complete the build Starting at a known point could help with this. You can consider using a clone or a backup as a starting point instead.	Faster The execution order remains consistent	If something goes wrong, you’ll need to run undo scripts or clean up the database on your build environment If you want to make changes to your versioned migration script, you'll need to undo it.

Feedback

What approach do you use? Or, do you do something else? Please email the development team. We'd love to hear more about your build process.

Redgate Flyway

Build strategies