The way that CI loads migrations (first schema:load followed by db:migrate) means that since most devs check in both at the same time, the schema migration code never gets exercised.
For an IRL case of this happening, see: codetriage/CodeTriage#1845
The reason we run schema:load first is because db:migrate can be slow to execute (each migration sequentially/serially) and it can "break" over time. For example: The CodeTriage cannot run rake db:migrate on a fresh database right now. This is common in large Rails apps. The schema:load applies the "current" database schema in one shot, so it's more reliable. But it comes with this downside that db:migrations aren't being run.
If we had more information and we could distinguish when a new migration is added, we could:
- Run
rake schema:load (gives us the latest)
- Run
rake db:rollback or rake db:migrate:redo with the added schema versions
That would exercise the migrations and guarantee they work. We have the timestamps baked into the migration filename, but we don't have a strong signal for when the last time migrations were run. I forget what git information we have, but we could possibly do some sort of a diff. That would be reliable.
There's also a cache for the buildpacks running test-compile, but I'm not 100% sure of the semantics of where it "inherits" from. The API for bin/test isn't even documented in https://devcenter.heroku.com/articles/buildpack-api. We wouldn't want multiple competing test runs to over-write this schema information in the cache.
The way that CI loads migrations (first
schema:loadfollowed bydb:migrate) means that since most devs check in both at the same time, the schema migration code never gets exercised.For an IRL case of this happening, see: codetriage/CodeTriage#1845
The reason we run
schema:loadfirst is becausedb:migratecan be slow to execute (each migration sequentially/serially) and it can "break" over time. For example: The CodeTriage cannot runrake db:migrateon a fresh database right now. This is common in large Rails apps. Theschema:loadapplies the "current" database schema in one shot, so it's more reliable. But it comes with this downside that db:migrations aren't being run.If we had more information and we could distinguish when a new migration is added, we could:
rake schema:load(gives us the latest)rake db:rollbackorrake db:migrate:redowith the added schema versionsThat would exercise the migrations and guarantee they work. We have the timestamps baked into the migration filename, but we don't have a strong signal for when the last time migrations were run. I forget what git information we have, but we could possibly do some sort of a diff. That would be reliable.
There's also a cache for the buildpacks running test-compile, but I'm not 100% sure of the semantics of where it "inherits" from. The API for
bin/testisn't even documented in https://devcenter.heroku.com/articles/buildpack-api. We wouldn't want multiple competing test runs to over-write this schema information in the cache.