Flyway

Drift Detection

Drift means that the database has changed in some way since the last deployment (e.g., a hot fix on Production.)  Drift detection can be setup as part of a pipeline process using Flyway Enterprise's check -drift command.  This allows you to check for drift as part of a deployment, which is a great way to understand what has changed and determine if there may be a problem with the deployment.  It's also good to understand these changes and reflect them in your earlier environments to be able to catch issues sooner.  You may also want to monitor for drift on a regular basis (e.g, nightly) to find out about drift sooner (see below).

The built-in drift detection in flyway check is currently checking for schema changes only.  You can build static data drift detection using Redgate's data comparison command lines/docker for SQL Server and Oracle. 
If you'd like to add your support for adding static data drift detection into flyway check, please add your votes/comments.

Monitoring for Drift

Wouldn't it be nice to find out about drift in more real time instead of right before a deployment?  Then you can bring your Development and Test environments in line with your Production environment to catch deployment issues sooner before going to Production. 

If you are using SQL Monitor, you can get drift alerts.  

Flyway Enterprise also comes with our comparison technology cmdlines, you can setup automated drift checks more frequently. Some options are:

  1. If you know Production should be at a specific version, then use the Git cmdline to checkout this version to a folder.  You can then use the comparison cmdline to compare this folder to the Production database or to the latest backup of the Production database.
  2. If you take full Production backups every night, you can compare today’s backup with yesterday’s using the comparison cmdlines.  If there any differences, alert that something has drifted.  This is nice because it doesn’t rely on touching the Production database at all.

These checks could be scheduled as a nightly job (or however frequently they want).  It's best to try to limit the use of your actual Production Database if possible and use backups or snapshots where possible.

For more information:


Didn't find what you were looking for?