Shell commands for development, staging, and production parity for Heroku apps.
gem install parity
Or bundle it in your project:
Parity requires these command-line programs:
git heroku pg_restore
Backup a database:
production backup staging backup
Restore a production or staging database backup into development:
development restore production development restore staging
restore-from reads better to you, it's the same thing:
development restore-from production development restore-from staging
- Note that the
restorecommand will use the most recent backup (from staging or production). You may first need to create a more recent backup before restoring, to prevent download of a very old backup.
Push your local development database backup up to staging:
staging restore development
Deploy main to production (note that prior versions of Parity would run database migrations, that's now better handled using Heroku release phase):
Deploy the current branch to staging:
Note that deploys to non-production environments use
git push --force.
Open a console:
production console staging console pr_app 1234 console
Migrate a database and restart the dynos:
production migrate staging migrate pr_app 1234 migrate
Tail a log:
production tail staging tail pr_app 1234 tail
The scripts also pass through, so you can do anything with them that you can do
heroku ______ --remote staging or
heroku ______ --remote production:
watch production ps staging open
You can optionally parallelize a DB restore by passing
as a flag to the
development restore-from production --parallelize
stagingremote pointing to the staging Heroku app.
productionremote pointing to the production Heroku app.
heroku git:remote -r staging -a your-staging-app heroku git:remote -r production -a your-production-app
- There is a
config/database.ymlfile that can be parsed as YAML for
If you deploy review applications with Heroku pipelines, run commands against
those applications with the
pr_app command, followed by the PR number for your
pr_app 1234 console
This command assumes that your review applications have a name derived from the
name of the application your
staging Git remote points at.
If you have Heroku environments beyond staging and production (such as a feature
environment for each developer), you can add a binstub to the
bin folder of
your application. Custom environments share behavior with staging: they can be
backed up and can restore from production.
Using feature environments requires including Parity as a gem in your application's Gemfile.
Here's an example binstub for a 'feature-geoff' environment, hosted at myapp-feature-geoff.herokuapp.com.
#!/usr/bin/env ruby require "parity" if ARGV.empty? puts Parity::Usage.new else Parity::Environment.new("feature-geoff", ARGV).run end
Please fill out our issues template if you are having problems.
CONTRIBUTING.md for details.
Please see the releases page for the version history, along with a description of the changes in each release.
See guidelines in
RELEASING.md for details
Parity is © 2013-2021 thoughtbot, inc. It is free software, and may be redistributed under the terms specified in the LICENSE file.
Parity is maintained and funded by thoughtbot, inc. The names and logos for thoughtbot are trademarks of thoughtbot, inc.