Redgate Flyway

Deployment approaches with Flyway

Flyway supports State-based and Migrations-based deployments. Each method has its advantages. The choice depends on the context of the project and your working practices.  The State-based approach has less to set up, but offers less control since you cannot edit the deployment script directly.  The Migrations-based approach offers full control over the deployment script and has more built-in auditing of these scripts.

Differences at a glance:


State-based deployments

Migrations-based deployments

Approach

Changes are applied by comparing and updating a target database to the desired state.

Incremental. Changes are captured in migration scripts that are tracked and executed on target databases.

Source of truth

The schema model - a set of files representing the latest state of each object and static data in your database.

The set of migration scripts - capture exactly how to modify a target database.  

Control 

Flyway decides how changes are applied and the order. 
Version control branching strategies can be used to deploy a subset of changes.

Fine grained control. Changes are captured in migration scripts, which can be modified and re-ordered, if required. 
Also, supports script migrations (PoSh, bash, etc.) and callbacks, which provide even more control over the deployment processes.

Working practices 

Control over how changes are expressed largely sits with Flyway.
Manual reviews are strongly recommended when automated.

Users who make changes have fine grain control over how changes are expressed, allowing for full automation. 
Lots of teams will still have a manual review before Production deployments.

Visibility

Flyway decides how the change is applied.

Changes are described in migration scripts which lend themselves to inspection. 

Audit trail and reporting

The object changes are captured in version control, but the actual script is not captured in Flyway.  It can be saved as part of a release management process.

Migration scripts are tracked in version control and in the target databases and can be audited. 
Flyway can raise issues if versioned scripts are modified after being applied to ensure consistency.

Reversibility 

Can revert to the previous state.

Each migration script can be individually undone.

Ideal for

Teams just getting started and may not be looking for full automation.
Environments where changes are simple in nature and low risk. 

Teams looking for full control over the deployment script and deployment can handle complex modifications like table/column renames and dealing with transactional data updates. 

Limitations

Manual intervention required for certain types of changes.
Will revert drift, which may not be desirable.
Automation should have manual reviews.

A little more set up than the state-based approach requires.

Learn more

Learn more about state-based deployments

Learn more about migrations-based deployments

You can configure the approach for your project when you create a new project.  You can change this later in the project settings.

Not sure where to start? 

If your not doing a lot of transactional data updates, then start with state-based deployments.  You can get setup a bit quicker and you can move to a migrations-based approach later.



Didn't find what you were looking for?