Deploying database changes using Flyway

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.

Flyway Enterprise enables additional functionality in your pipelines by utilizing for MySQL, Oracle, PostgreSQL, and SQL Server.

With Flyway, 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.

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.

Didn't find what you were looking for?