production data migration patterns in continuous delivery

Flyway works great for continuous delivery/deployment. Many clients use it across all environments, including production.

The single most important thing for cascading DB migrations across environments is to have a 3 step process:

Step 1

Old application code works together with old DB.

Step 2

New application code get deployed, and migrates DB on startup. This migration must be backwards-compatible so that old application code still works with the new DB. This is essential because:

• you can then do rolling upgrades, upgrading one node at a time until all nodes have the new application code
• rollback immediately to the old application code if the new one is broken

This step may involve compatibility views and triggers to do the job.

Step 3

After the changes have been proven to work, the next version of the application code getsdeployed together with the necessary DB migrations to discard any remaining outdated (from step 1) and compatibility (from step 2) structures.

Implement changes to your database as single (raw) sql files, then use sqlpatch to build a migration script.

I usually have a single git repository for the database alone and a cd environment attached to it. I usually have a production and a development database that are automatically migrated when I push to corresponding branches.

This setup makes is very easy to setup another database for a feature branch and to experiment with it. Sqlpatch takes care of all the dependencies in the separate sql files so that I can easily merge a feature branch in another branch.