With Flyway migrations, you may create rich pipelines complete with:

• Dry run script (flyway check -dryrun)  Teams/Enterprise
  Have a record of the exact SQL that was executed on the target environments or use a manual intervention and approval step in your pipeline to review the SQL that will be executed on a target before deploying it.
  
  
• Changes report (flyway check -changes) Enterprise
  This report show at a glance how many objects will change and what the change is.  This can be useful during manual intervention and approval steps in your pipeline to understand exactly how each object will change and give DBAs a better understanding of the changes to determine if more review is needed.  They also come in handy after releases as an audit of change or helping to diagnose issues.
  
  
• Drift report (flyway check -drift) Enterprise
  This report shows if there are any schema changes in the target environment that did not flow through the pipeline.  For example, someone may have made a hotfix on Production.  It's important to know about these changes to make sure your latest release doesn't conflict with the change.  It's also important to know about drift so you can reflect this in your earlier environments to have more realistic dev/test environments and catch issues earlier.   
  
  
• Code analysis (flyway check -code) customize with Enterprise
  Run static code analysis checks to catch issues early.  Rules can be turned on or off and configured to fail builds.
  
  
• Deploying to target databases (flyway migrate) Community/Teams/Enterprise
  Execute any pending migration scripts against the target database.
  
  
• Rolling back (flyway undo or compare the target with the output of the build; see /Report and /ReportType: for SQL Server and Oracle) Enterprise
  Use Undo scripts to reverse a versioned migration script.  
  If you use our comparison technology at deployment time, this gives you a starting point to undo changes.  If there's table or data manipulation involved, then you'll need to have better recovery plans in place like backups, rolling forward, manual recovery, or Undo scripts.
  

Note: If you did not use Flyway Desktop and your downstream databases already have objects in them, then you will need to baseline your downstream environments first.  In Flyway Desktop, we set baselineOnMigrate=true and baselineVersion=<your_baseline_version_number> in the project settings so this will automatically be done the first time your pipeline runs.  Once your downstream environments are baselined, use these Example CI/CD Pipelines to setup your own pipeline for deploying database changes.

Resources:

• Baselining your downstream environments
• Example CI/CD Pipelines
• Implementing a roll back strategy