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.
brew tap thoughtbot/formulae brew 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
You can rename the existing production app like this:
git remote rename heroku production
The typical command is
Deploy current branch to staging:
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:
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.
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
staging console production console
You get the gist