Heroku has recently introduced a feature called release phase. Release phase (beta) enables you to run scripts or executables in a slug when a new release is created. The commands/scripts run as a separate process before the app is made available to the end users.
Heroku will run the command defined by the release process type in your Procfile. A one-off dyno will be started to run the command and it can run for up to 24 hours. Apart from running database migrations the release phase can also be used for:
- Priming or invalidating cache stores
- Sending CSS, JS, and other assets from the slug to a CDN or S3 bucket
Release phase is awesome for handling failed migrations. If a migration fails, the new release is aborted without impacting users. Because Rails migrations operate within a transaction, your database will be just as it was before the failure.
You can find the Procfile at the root of your app on Heroku. Here’s how your Procfile is supposed to look like in order to utilise Release Phase for automatically running database migrations:
web: bundle exec puma -C config/puma.rbrelease: bundle exec rake db:migrate
See the release: bundle exec rake db:migrate This is the line of code that will run automatically before the new release is available to the end users each time you deploy.
Checking release status and debugging
To check the status of releases including those that failed
$ heroku releases === coolcat-storm-28392 Releases - Current: v32 v33 Deploy ad7c527 release command failed [email protected] v32 Deploy b41eb7c [email protected] v31 Deploy 38352d3 [email protected] ...
Canceling a release command
We need to find the one-off dyno running the release command before we can cancel it. Run this command to list the currently running processes
$ heroku ps === release (Free): bundle exec rake db:migrate release.3129: up 2016/02/01 12:17:45 (~ 2s ago)
Now terminate the one-off dyno using its name
$ heroku ps:stop release.3129