Flyway can check a target environment for drift, validating that no unexpected changes have been made since Flyway was last used to deploy to the database.

This is most commonly used ahead of a deployment, ensuring that the target environment is still in the expected state for executing the deployment.

When deploying using migrations, drift will likely only cause an immediate problem if objects have drifted which are being modified in the migrations being deployed. Migration deployment will otherwise naturally ignore any drift.

When deploying from the schema model, drift will be reverted as part of the deployment, unless ignored using comparison filters.

What is 'Schema Drift'?

Schema Drift occurs when a target database deviates from the codebase that was used to originally deploy it.

In this example, modifications were made to the live database after Version 1.2 was released. This effectively created a new version of the schema outside source control.

This could cause a problem when Version 1.3 is deployed, because the deployment package will expect the target database to be in the state of Version 1.2.

How Flyway drift detection works

Flyway uses database snapshots in order to perform drift analysis. There are two alternative approaches to making this work, both of which rely on the Flyway check  command, using the drift  flag:

Option 1: Capture a snapshot of the database after every deployment and persist it for reuse

In this approach, every time a deployment is run, a snapshot is taken immediately after the deployment to capture the state of the database.

The snapshot then needs to be persisted in a repository so that it can then be retrieved whenever you want to perform subsequent drift checks.

This snapshot can then be compared directly against your database (or a new snapshot of it) ahead of a new deployment.

The benefit of this solution is that it works for both migration and schema model deployments, and it only captures drift since the last deployment. It also doesn't require a build environment to work.

The main drawback with this approach is the overhead of persisting the snapshot between deployment runs, and the approach here will vary depending upon your build infrastructure.

Option 2: Use a build environment to capture migrations at different stages of deployment

In this approach, Flyway performs the following steps (via a single check command invocation):

• Take a snapshot of the target environment
• Clean the build environment
• Query the target environment for the list of applied migrations
• Apply these migrations to the build environment
• Take a snapshot of the build environment
• Compare the two snapshots
• Report on drift

Configuring which objects are included in drift reporting

By default all objects which are different will be reported on, whether modified or existing only in the target.

Drift analysis uses the same database comparison configurations as are used for generating the schema model or for automatically generating migrations. This includes static data settings, so configured static data differences will also be picked up.

It is possible to override the filtering logic for drift analysis by configuring a filter file parameter on the check command.

Resolving instances of drift

The first step to resolve drift is to make a decision about whether the drift should be reverted – in other words, if the target environment should simply be brought back in line with source control – or whether the drift should be left in place and the change representing the drift should be imported into source control.

A team may make quite different choices depending on the nature of the drift and the use case for the target environment.

Resolving drift when deploying using migrations

Option 1: Revert drift from the database

To bring the deployment target back in line with the previously deployed version in source control, it is possible to generate a drift revert script.

You can then execute this script against the target database and proceed as normal.

Option 2: Ignore the drift

Drift will likely only cause an immediate problem if objects have drifted which are being modified in the migrations being deployed. Migration deployment will otherwise naturally ignore any drift, so it is possible to just go ahead with the deployment.

Where the drifted objects exist only in the target database, it might be better practice though to explicitly filter out the drifted objects (see above) and rerun deployment.

Option 3: Incorporate the drift into the release

Flyway can be used to generate a new migration script capturing the drift.

This script could then be added to source control via normal practices. It then needs marking as already executed against the target database, before proceeding with the deployment.

Resolving drift when deploying using the schema model

Option 1: Revert drift from the database

Deploying from the schema model makes the target match the schema model, so by default it will revert all drift in addition to the changes you made in source control.

So to revert drift, just proceed with the deployment as normal.

Option 2: Ignore the drift when objects exist only in target

It is not possible just ignore drift when deploying from the schema model.

Although, where the drifted objects exist only in the target database, it is possible to filter out the drifted objects (see above) and rerun deployment.

Option 3: Incorporate the drift into the release

In order to incorporate drift the schema model would need to be updated from the target environment with custom filtering to only include the drifted objects.

The updated schema model could then be committed to source control and the deployment rerun.