There are three development approaches (or models) that can be employed when using Flyway. This article will introduce them and discuss the mains pros and cons of each, as well as drilling down into some of the more advanced workflows and considerations associated with each.

The three approaches

For simplicity we will are describing three broad approaches, but many elements and principles described in one approach can be adapted to another. Development teams may choose to adapt the approaches to their own needs.

The migrations-first approach  

In this model, the sole source of truth for both development collaboration and deployment is the set of migration scripts. If development teams are maintaining a schema model (a feature of Flyway Teams and Flyway Enterprise), it is for the purpose of having an object-level audit and history and not used as a means for collaborating on changes nor as a source for creating migration scripts.

In this model, developers create migration scripts and push them to their VCS repository when they have database changes that are ready to share or deploy. When developers take on database changes created by others, they will pull new migration scripts to their local working folder and run flyway migrate to apply the changes.

For deployment, these very same migration scripts are applied using flyway migrate against downstream test environments all the way to production.

The state-first approach

FLYWAY TEAMS FLYWAY ENTERPRISE

The source of truth in a state-first approach is the schema model, which is a set of files each representing the latest state of the object. Migration scripts are not authored by developers.

In this model, developers will use Flyway Desktop to save database changes to their local schema model. When ready, these changes are pushed to a common development branch. Other developers on the team will use the Apply to Database feature in the Schema Model screen in Flyway Desktop to update their local dev databases with the latest changes. Flyway Desktop will compare the state of the schema model with the state of the database and will auto-generate and auto-apply an update script.

A similar approach is taken at deployment time. Flyway will compare the schema model with the downstream target databases and will generate a deployment script based on the differences between the schema model and the target database schema.

The combined state and migrations approach

FLYWAY TEAMS FLYWAY ENTERPRISE

 This approach takes the best of both state and migrations and applies them to the development process and the deployment process accordingly. The state model becomes the source of truth for development collaboration, and the set of migrations is the source of truth for deployment. This decoupling means that developers who want to share changes with other developers aren't forced at this early state to create artifacts that will impact how and in which order the changes are eventually deployed to the customer.

As in the state-first approach developers will save and collaborate on changes by saving them to and applying them from the schema model using Flyway Desktop. 

When ready to deploy, developers or DBAs can create migration scripts based on the changes that exist in the schema model. As with the migrations-first approach, deployments rely on running migration scripts against the downstream environments.