This is a simplified, but fairly thorough, set of scripts and configuration to enable Heroku Release Phase for Rails apps.
Further, this particular set up plays nicely with Heroku Review Apps in that the release
phase script will:
- Fail, loudly, if the DB does not yet exist.
- Load the DB schema if the current schema version (as determined by
bin/rails db:version
) is0
. - Run DB migrations otherwise.
For a "normal" app that usually means it will run the DB migrations.
For a Review App, on the first deploy the release
phase will bin/rails db:schema:load
.
And then the postdeploy
script will seed data.
During subsequent deploys to the Review App, the release
phase will bin/rails db:migrate
.
@pebneter My initial reaction is to dig into why you have two different apps, running the same code, sharing a database. Could you provide any context there?
Ignoring that for now, ultimately the setup you're describing is... unusual. And without more context as to the why, I can only offer generic suggestions, which might be Bad Ideas™, depending on the missing context. e.g., pick one App to be the "leader" which manages the DB, while the other is a "follower," totally dependent on the DB maintenance of the former. Something like an ENV Var to determine this is probably doable, with your Release Phase script checking that an NOOP-ing in the follower case.
Or you could look into something truly terrible like a global, distributed locking mechanism, complete with all of the sharp edges and broken corners that come with them. e.g., PostgreSQL Advisory Locks, or a Redis lock, etc...
I'm quite curious to hear more about the why, so please do share if you can!