How can we make migrations better?

[jbuck]

Today we had an small amount of downtime when a migration was not run against the production database before pushing the application code to production. How can we prevent this from happening in the future?

[sedge]

I might be wrong, but I thought the point of Knex migrations was to automatically update schemas when they change without losing data. If this is true, we should be able to add that as a step to the deploy process no? Are we using Knex incorrectly?

cc: @ashleygwilliams

[Pomax]

What is the deployment process right now? It sounds like we're missing the migration step when moving from staging to production. I don't see a postinstall script in the package.json, so it might be that we just need to add a postinstall call for npm run migrate (rather than npm run knex, which runs migrate+seed, the latter of which is not very useful to run every time a prod push happens), so that instance that already have an .env file or heroku vars, with a working database attached, get automigrated.

[jbuck]

@sedge As we've learned, depends how you code your migrations! :) But generally speaking, yes, migrations should be safe to run at all times. And unsafe migrations should be caught/changed in code review.

@Pomax Heroku auto deploys master to staging and there's a human-pressed promotion button to production

[sedge]

Okay, so what this means is we need to:

1. Always confirm that modifications to the migration scripts leave them safe
2. Hook migrations into the promotion process, or stop using heroku pipelines and deploy using travis-ci hooks