While working on bug 1367054, I discovered that local database initialization is broken in cases where you're adding a new column (vs the most recent prod dump) for tables that don't get exported (eg: rules_scheduled_changes). The current process for database init is: * Create the entire new database, upgrading it to the most recent local version * Import the latest production dump -- which ends up overwriting the migrate_version. * Re-run the upgrade So, any changes to the db schema between the prod dump and local, AND that aren't reverted by importing the prod dump, will end up causing errors. I think the best way to fix this is to simplify our init as much as possible. Maybe instead, we should: * Create an empty database * Import the prod dump * Run the upgrade script This would require that prod dump creates all tables, but we could continue to not dump data for some of them (such as scheduled changes, permissions, etc.)

This is going to be needed to support the new stage environment that we want for staging Releases.

Commit pushed to master at https://github.com/mozilla/balrog https://github.com/mozilla/balrog/commit/6d22c6df2f74dc85a5e864a0f8237a2a93285692 bug 1376331: improve database initialization for dev environments - dump entire database schema. r=nthomas

Commit pushed to master at https://github.com/mozilla/balrog https://github.com/mozilla/balrog/commit/faf0379d90570ccbab39de5229362c927822e196 bug 1376331: improve database initialization for dev environments (#397). r=nthomas