Flyway Desktop provides a powerful GUI on top of Flyway , the helps you easily version control your database schema and generate migration scripts for SQL Server, PostgreSQL and Oracle databases. 

Flyway Desktop saves the definitions of your database objects into a schema model. You can version control and share changes to the schema model with teammates to rapidly iterate on new development.

When you are ready for a deployment, you generate migration scripts to deploy these changes safely.  Migration scripts are committed to version control and are can be used as part of an automated CI/CD process to validate and deploy database changes to other environments (e.g., Test, Staging, Prod).

Why should you version control your database schemas?

Flyway Desktop allows you to easily save the definitions of objects in your database to a schema model. The schema model is a set of text files within your project which contains the DDL scripts of your database schema. 

You can version control your project by using the native Git client in Flyway Desktop, or by using the version control client of your choice (for any version control system). 

Once you have committed your project containing your schema model to version control, other team members may access the project via version control. We recommend that each team member develop changes in dedicated development database environments, and Flyway Desktop allows team members to apply the schema model from the project to their development database to bring it up to date.

Version controlling your database schema into a schema model with Flyway Desktop has the following benefits:

•  The schema model automatically maintains an object level history for your database with full object definitions. This enables you to:
  • Find out when changes happen
  • Find out who made them and why, by reviewing history and commit messages in your version control system
  • Identify conflicts when multiple team members have modified the same object
• The schema model allows a lightweight way to share work-in-progress when the final set of changes is not known
  • This allows team members who are less fluent in SQL to make changes in the IDE or GUI of their choice and easily commit the schema 
  • For teams who deploy database changes once a sprint or less often, this can save considerable time as deployment code need not be considered constantly

Why should you generate migration scripts for deployments?

Flyway Desktop enables you to generate and track migration scripts from the schema model.

Flyway Desktop does this by helping you create a baseline script when you are working with an existing database which has already been deployed to production. The baseline script captures the state of the database schema at the beginning of your work. Flyway Desktop allows you to configure a shadow database. Your baseline script (if present) and any additional migration scripts are executed against the shadow database to validate the scripts to ensure they can be deployed successfully.

Additionally, Flyway Desktop utilizes the shadow database to compare your schema model with the result of all of your migration scripts run on the shadow to view new changes in the schema model and generate additional migration scripts . 

Generating migration scripts early in the development process as you prepare a deployment has the following benefits:

• You gain control over exactly how changes for the database are executed
  • You are able to review and edit the code in migration scripts early in the deployment process
  • Migration scripts are version controlled as part of the project, providing a clear audit trail of the code used in deployments
• Easy integration of data modification scripts into the release process

Flyway Desktop offers flexible workflows

There are 3 workflows that we see when using Flyway Desktop.

1. Migrations-first workflow

Migration scripts are written by developers or given to a team from a third-party.  These scripts can be placed directly in the migrations folder on disk.  You can then use Flyway Desktop to apply the migration scripts to a development database.  If you are using a database engine that we have a comparison tool for, you can then save the schema model to disk to obtain the object level history for each object.

2. Continuous Delivery workflow - each developer is responsible for generating their migration scripts

If you are a team who deploys database changes frequently or a team where everyone is comfortable writing SQL, you may prefer for each team member to both save changes to the schema model as well as generate migration scripts each time they commit a change

3. Database Release Engineer - developers make changes to the schema model, but the migration script is generated at release time