Migration scripts can be manually deployed to target environments using the Migrate tab in Flyway Desktop. 

To automate your deployments, use the Flyway command line or Docker container.

For Oracle, PostgreSQL, and SQL Server (and coming soon MySQL), Flyway Enterprise enables you to bring additional functionality into your pipelines by utilizing the Flyway command line or Docker image.

With Flyway, you may create rich pipelines complete with:

• Dry run script (flyway check -dryrun)
  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)
  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)
  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)
  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)
  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)
  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.
  

Be sure to review the Example CI/CD Pipelines to see how these work.

If you are looking to deploy from the schema-model for databases with object-level history support, see Deploying using the schema model.