Development teams can adopt Flyway and benefit from its powerful auto-generation of migration scripts while preserving their established database development process.

For example,

• Many teams use ORMs, such as Hibernate, Entity Framework, JOOQ and others.
• SSDT Database Projects are popular for those using Visual Studio and SQL Server.
• Some organizations may have built their own bespoke database development processes and have no strong reason to change.

Although organizations might choose to preserve their database development approach, often it doesn't come with a sufficiently robust and reliable deployment capability. Flyway will seamlessly slot into these existing development processes to provide:

• Automated generation of versioned migration scripts to be used in downstream deployment
• The generation of undo migration scripts in case rollback is required. 
• A schema model extracted to version control to build up an object level history.

Process

1. Developers should use their existing process to develop and test their database changes. When these changes have been validated as "ready", they are applied to a centralized development database.
2. When these changes are ready to be deployed, an automated process powered by Flyway is triggered (running a batch file or triggering a pipeline in a CI tool). This process will:
   1. Check out the project from VCS
   2. Use the Flyway CLI to save any database changes from the development database to the schema model folder on disk. 
   3. Use the Flyway CLI to generate migration and undo scripts.
   4. Commit/push the schema model changes, migration scripts and undo scripts to VCS.
   5. Open a Pull Request.
3. The migration script and undo scripts can now be reviewed as part of the Pull Request. To help the review, individual object changes are represented as changes to the schema model. 

The above process can be supplemented by additional checks. For example, if a change report is desired to help with the PR review, it can be generated as an artifact of the CI process.

In the case where a subset of changes need to be selected for the migration script:

1. Edit the migration script and undo script as part of the process described above.
2. Reject the PR and use Flyway Desktop instead to select a subset of the database changes to generate a migration (and undo) script for. 
   
   

If a manual migration script is needed:

If some developers on the team want to create their own migrations scripts with Flyway Desktop or the CLI they should be able to do so in parallel with the above process.  They may be needed to write migration scripts that can't be auto-generated using our comparison technology.  An example of this may be a one-off script that needs to update some transactional data.

Example Code: