Flyway 4.0 Released

2015 is behind us and what an amazing year this has been for Flyway! Now that Continuous Delivery and
database migrations are entering the mainstream, Flyway is seeing even more adoption and recognition than ever before. As a testimony of this, last year Flyway
was honored with the highest distinction "Adopt" on the ThoughtWorks Technology Radar.

And it's really been quite a ride since the project's humble beginnings on
Google Code (yes, that used to be a thing) in 2010. Every single year has come with tremendous growth, and
last year was no exception. In fact Flyway passed 850,000 downloads in 2015 alone!

So let's kick off 2016 with a bang! Please welcome Flyway 4.0!

The highlights of this release are:

Repeatable Migrations support

Sybase ASE, SAP HANA and Apache Phoenix support

Java-based migration and callback enhancements

Improved compatibility with schema-first persistence frameworks

Improved compatibility with Git

Disabling clean

Datasource auto-configuration when running in Boxfuse instances

Commercial support plans

Repeatable Migrations support

Versioned migrations are a great way to evolve your relational database schema. You can think of them as
transformation functions you apply to your schema. They let you reliably evolve the structure
of your database by creating, altering or dropping objects like tables and indexes. Versioned migrations are also a
great way to evolve reference data or perform bulk corrections of user data.

There are however a few areas where they tend to create some friction. This usually occurs when you either
manage code (think stored procedures, functions, packages, ...) or manipulate objects, like views, that don't physically hold data
themselves. In those cases, it's easy to end up over time with many almost identical copies of the definition
of the same objects scattered over many different migration files. This feels wrong and simply doesn't make sense when you
could just as well be keeping the history within your version control system.

To better support these scenarios we are today expanding Flyway beyond versioned migrations and introducing a new type of migrations: repeatable migrations.

Here is a brief example:

R__My_view.sql

CREATE OR REPLACE VIEW my_view AS SELECT * FROM my_table WHERE name LIKE 'My%';

As you can see we have a number of differences compared to versioned migrations:

It has a different prefix (configurable of course): R instead of V

It has no version number and no order compared to other migrations

It can be run multiple times (thanks to the CREATE OR REPLACE clause)

You can now evolve the definition of this view within the same file. History will be kept in your version control system
and Flyway will reapply this migration every time the checksum changes and previous runs will be marked as superseded.

The same migration will therefore appear multiple times in your history:

You can start using this today with both SQL and Java-based migrations.

SAP ASE, SAP HANA and Apache Phoenix support

As Flyway increasingly becomes our industry's de-facto standard for database migrations, the
ever growing list of supported databases keeps on expanding. With Flyway 4.0, we are
adding support for not one, but three new databases: SAP ASE (previously known as Sybase ASE), SAP HANA and Apache Phoenix:

Flyway now supports a total of 19 different RDBMS.

Special thanks to Jason Wong for contributing SAP ASE support and Josh Mahonin for contributing Apache Phoenix support.

Java-based migration and callback enhancements

During the Flyway 3.x series we introduced a number of configuration options and lifecycle hooks including callbacks.
Just like migrations, callbacks can be written either in SQL or in Java. When writing them in Java unfortunately
there was no easy way to access Flyway's configuration. We decided to remedy this with Flyway 4.0. Both Java-based migrations
and Java-based callbacks can now implement the ConfigurationAware interface (or inherit from either
BaseJdbcMigration or BaseFlywayCallback) and gain access to the Flyway configuration
which will be automatically injected at runtime:

Improved compatibility with schema-first persistence frameworks

We are strong believers in contract-first development and when it comes to the database, your schema is the contract
between your application and the DBMS. This is a natural fit for tools like jOOQ
that generate their persistent model directly from a freshly migrated schema.

Yet in the past Flyway's Maven, Gradle and SBT plugins looked for migrations in the target directory of the project,
which created a chicken and egg situation where they only solution was to split the project into separate modules of which
one would first migrate the database before the next one would then generate the persistence classes and compile the code.

We decided to fix this in Flyway 4.0 by changing the defaults where the Flyway build tool plugins look for migrations:

Flyway 3.x default location

Flyway 4.x default location

Maven, Gradle, SBT

classpath:db/migration

filesystem:src/main/resources/db/migration

So if you don't need Java-based migrations, Flyway 4.0 will now be much easier to use with schema-first persistence frameworks like jOOQ.

Improved compatibility with Git

Git has definitely won the version control system war. Yet it comes with this widely used "feature" called
core.autocrlf=true which
automatically adjusts the line endings of text files based on the operating system you currently use.

While this sounds great in theory it actually causes a number of problems with teams using different operating systems.
One of them was Flyway checksum
failures as the files now have different contents on Windows than they do on Linux and Mac.

To address this Flyway 4.0 now ignores line endings when calculating checksums and all existing checksums
in your metadata table will be automatically adjusted on first run to be compatible with this new algorithm.

Disabling clean

Clean is an incredibly useful operation in development. With a single command you can wipe your database schema
completely clean of all its objects. This is a fantastic way to be able to experiment and quickly start over if
things don't work out.

In production however, running clean is usually something you ever do once as it is severely career-limiting.

To prevent such disasters we are introducing an additional safety measure. By setting:

flyway.cleanDisabled=true

Flyway will now refuse to clean your schema until cleanDisabled is set to false again. We recommend all Flyway users to active this on their production environments immediately.

Datasource auto-configuration when running in Boxfuse instances

Last year has been a very busy year for us as next to Flyway, we also launched Boxfuse.

Boxfuse is the easiest, most reliable and secure way to run your JVM-based apps on AWS. It is based on three core principles:

Immutable Infrastructure: Creating servers and never modifying them again by treating a server as one immutable unit that is regenerated after every change and promoted unchanged from environment to environment to eliminate drift and increase reliability by ensuring you run the exact same code in production as the one you tested in test.

Minimal Images: Analysing your application and generating minimal tailor-made Linux-based images on the fly that are 100x smaller than a typical Linux system and take just seconds to produce.

Blue/Green Deployments: Deploying a new version of an app in parallel to the existing one and only making the switch at the elastic IP or elastic load balancer level once the configured health checks of the new version have passed. Deployments are fully automated and effectively transactional, providing you with zero-downtime updates.

Boxfuse has been designed from the ground up for Continuous Delivery and integrates naturally with Flyway.
Boxfuse comes with special support for
Spring Boot, Grails, Play, Dropwizard, Tomcat and TomEE as well as regular executable jar applications.
It can use your framework's native configuration file to detect port and healthcheck information, based on which
Boxfuse will provision AMIs, Security Groups,
Elastic Load Balancers and Auto-Scaling Groups for you, with zero additional configuration required.

Boxfuse also detects whether your application uses MySQL or PostgreSQL and will automatically provision the necessary
AWS RDS instances as well as configure your framework of choice to use the correct JDBC URL, user and password.

And if you choose to use Flyway directly to migrate your database on application startup, it is now as simple as:

new Flyway().migrate();

as Flyway automatically picks up the database configuration exposed by Boxfuse.

We took the same principles you love about Flyway (simplicity, focus, power), and applied them to deploying applications on AWS.

Commercial support plans

If you have questions or need help, Flyway you can get answers via the flyway
tag on StackOverflow as well as the issue tracker.

Over the last few years we seen increased demand to go further and also offer professional dedicated support to organisations
who need guaranteed response times as well as the piece of mind knowing someone will be there when they need
assistance.

Today we are opening up our professional support subscription program
which we have offered to a selected number of clients in the past to
all companies using Flyway. These are the three support tiers we are offering:

Light

Business

Enterprise

Response Time

3 business days

2 business days

2 business days

Pre-release access

Yes

Yes

Yes

Contact

Email

Email

Email / Skype / Phone

Scope

Defects

Defects + Consultancy

Defects + Consultancy

Remote Consultancy

Not included

8 hours (4 x 2 hours)

24 hours (12 x 2 hours)

For more information about our professional support subscriptions, contact us at [email protected]

Special thanks

Grab it while it's hot!

Flyway 4.0 is out and it is a big one. Flyway now expands beyond versioned migrations and offers
Repeatable Migrations as well as
SAP ASE (previousls known as Sybase ASE), SAP HANA and Apache Phoenix support. Additionally, Java-based migrations
and callbacks now have an easy way to access the Flyway configuration, compatibility with schema-first persistence tools has been improved,
Git's autocrlf issues have been relegated to the past, clean can be disabled and when running within Boxfuse instances Flyway now auto-configures its datasource.