Parity: Managing Multiple Heroku Environments with Ease

Parity is a set of shell commands from thoughtbot that help you easily manage Heroku staging and production apps, such as deployment, sync production DB to staging, etc.

Wait.. Why do you need another tool?

Parity provides powerful database backup/restore commands. That could be a killer feature that draws your attention. You can accomplish the same task with Heroku CLI, it's just so much easier to do with Parity.

Also, once you have more than one Heroku environment like staging, it starts to be cumbersome to run Heroku CLI.

For instance, previously you can run commands like heroku config to get the config vars or heroku run rails console to enter the console. Now you'd need to append an argument of -r (staging|production) (shortcut of --remote) to every Heroku command to specify the environment.

Parity contains really intuitive and handy commands for it. I quite like the interface design. The learning curve is almost zero and the return is maximum.

Install

gem install parity

Double check your git remote setting

If you follow the Heroku docs to setup your first app, (usually the production one,) it's very possible that it's registered with the name heroku in your git remote repository:

$ git remote -v
heroku  https://git.heroku.com/myapp.git (fetch)
heroku  https://git.heroku.com/myapp.git (push)
staging https://git.heroku.com/myapp-staging.git (fetch)
staging https://git.heroku.com/myapp-staging.git (push)

Parity expects you to name your Heroku apps as staging and production.

You can rename the existing production app like this:

git remote rename heroku production

Usage

The typical command is [environment] [command].

Deployment

Deploy current branch to staging:

staging deploy

This is equivalent of git push -f staging $(current_branch):master.
This is the best one. Most of the time when I deploy to staging, it's one of those development/feature branches. Having staging deploy deploy current branch with --force option really showcases the developers understand the real pain and design the convention for it. Good job. 👏

Deploy master branch to production:

production deploy

Database operations

Restore the production DB to staging:

production backup
staging restore production

Restore the production DB into local development:

production backup
development restore production

You'll need a DB backup first. Once you got one, you won't need to run the backup command every time.

restore-from is an alias of restore, you can use it if you prefer the readability.

Migration:

staging migrate
production migrate

config vars, logs, consoles...

Inspect config vars:

staging config
production config

Check the log:

staging logs
production logs

Tail the log:

staging tail
production tail

Run console:

staging console
production console

You get the gist 😄

References

• https://robots.thoughtbot.com/how-to-back-up-a-heroku-production-database-to-staging
• https://github.com/thoughtbot/parity