Skip to content

Latest commit

 

History

History
25 lines (19 loc) · 1.96 KB

guide-database-migration.asciidoc

File metadata and controls

25 lines (19 loc) · 1.96 KB

Database Migration

When you have a schema-based database, you need a solution for schema versioning and migration for your database. A specific release of your app requires a corresponding version of the schema in the database to run. As you want simple and continuous deployment you should automate the schema versiong and database migration.

The general idea is that your software product contains "scripts" to migrate the database from schema version X to verion X+1. When you begin your project you start with version 1 and with every increment of your app that needs a change to the database schema (e.g. a new table, a new column to an existing table, a new index, etc.) you add another "script" that migrates from the current to the next version. For simplicity these versions are just sequential numbers or timestamps. Now, the solution you choose will automatically manage the schema version in a separate metadata table in your database that stores the current schema version. When your app is started, it will check the current version inside the database from that metadata table. As long as there are "scripts" that migrate from there to a higher version, they will be automatically applied to the database and this process is protocolled to the metadata table in your database what also updates the current schema version there. Using this approach, you can start with an empty database what will result in all "scripts" being applied sequentially. Also any version of your database schema can be present and you will always end up in a controlled migration to the latest schema version.

Options for database migration

For database migration you can choose between the following options:

  • flyway (KISS based approach with migrations as SQL)

  • liquibase (more complex approach with database abstraction)