New in Redgate Flyway Enterprise – Drift detection and rollbacks just got easier
In our latest Redgate Flyway Enterprise release, you can store a snapshot directly in the target database, making drift detection and rollback strategies easier and more reliable whether you’re using state-based or migrations-based deployments.
It started with a late-night production deployment. The team had tested everything in their QA environment, but when the deployment ran in production, it failed – hard. A column had been renamed manually weeks earlier during a hotfix and no one remembered. The change wasn’t in version control, wasn’t reflected in the dev and test environments, and wasn’t caught during pre-deploy checks. The result? A broken deployment, a rollback scramble, production downtime, and a very long night. Beyond the technical disruption, the team faced uncomfortable questions during the post-incident review about audit trails and change control – questions that get even more serious with regulatory compliance is on the line.
This kind of drift, where the production database diverges from the expected state, is exactly what Flyway’s drift check can prevent.
Why store snapshots in the target database?
Previously, snapshots were stored externally, which added complexity checking for drift or preparing for rollbacks. Now, with the new –saveSnapshot parameter, Flyway can automatically save a snapshot inside the target database at the end of a successful deploy, migrate, or undo command. This snapshot is stored in the snapshot history table, making it easily accessible for future operations.
- Drift detection becomes more reliable and faster. When you run check -drift, Flyway compares the current state of the target database against the stored snapshot to identify any unexpected changes. This helps catch manual edits, hotfixes, and schema changes made outside your Flyway deployment process before they cause deployment issues. It also helps maintain compliance by ensuring production environments match approved, tested configurations. Learn more about drift detection.If you were previously using a build environment for your drift detection, this extra infrastructure will not be required for drift checks that use a snapshot. The snapshot-based drift check should also perform faster.
- A rollback script can be generated based on a snapshot in the target database. The stored snapshot provides a known-good state that can be used to generate a script to restore the database to a previous version. Explore rollback strategies.Having reliable rollback options isn’t just about technical recovery – it’s a key component of change management governance, providing the safety net that allows teams to deploy with confidence while maintaining compliance with change control policies.
Next steps
- Integrate snapshot saving into your CI/CD pipeline to have reliable drift checks going forward. Learn more on our docs.
- Use drift detection reports as part of your compliance documentation to demonstrate environmental consistency and change control adherence to auditors.
- You can also run drift checks on a regular basis so issues are found as soon as possible and not right before you’re deploying to Production.
- Use snapshots to inform rollback decisions. Snapshots should only be used as a starting point for generating rollback/roll forward scripts. They need to be reviewed carefully, especially if there are data changes. More rollback guidance here.
This update is all about making Flyway easier to check for drift so you can catch issues before your next deployment and gives you a starting point for rolling back/rolling forward if something does go wrong.
Let us know what you think about this feature. You can leave a comment below, email our development team, or sign up for a 30-minute zoom session with the development team. We love hearing about how Flyway fits into your workflow and figuring out more ways to make it easier.