Deploy Usage

With migra you can dispense with schema version numbers and multiple migration files.

Different deployment styles

Migra doesn't force a precise workflow onto you, because every project is different. Instead, migra was designed to allow you to easily script up the workflow you want, help you automate it as fast as possible, and help you test your database changes to ensure correctness.

Nevertheless, here's some guidelines about how set things up just right.

App-driven vs database-driven

Broadly speaking there are two ways to manage changes to an application database, which we might call app-centric and database-centric. You can use migra to enhance either style, however you'll use it quite differently depending on your preferred situation.

With the app-centric approach, you add migration files to the same repository as your application code. When you deploy, any new migration files that haven't yet been applied to the production database get run before the app code is deployed.

The database-centric approach is more common in an environment where you have separate people responsible for the database. Sysadmins or DBAs manage database changes as a separate task. App and DB deployments are more loosely coordinated and not run at the same time as part of the same deployment.

The key feature of both is to directly use the production schema generate the changes needed.

Migra with app-driven deployments

Instead of manually crafting migration files and mucking about with version numbers, you can do the following.

Migra with database-centric deployments

The flow with a database-centric application might look like this: