When I first started Rails, I completed the Ruby on Rails Tutorial by Michael Hartl. During that journey on best practices, I was led to sign up for a strangely named service called Heroku where my apps would magically work with a simple git push. I could focus on learning code and let someone else worry about dev ops.

Fast-forward many years and I still use Heroku. Turns out, it continues letting me focus on writing quality code while someone else worries about the reliability, scaling, and security of my servers.

Improving on an already great experience

So how could Heroku possible be any easier? Well, I’ll tell you. There is a great dev tool called Parity written by the great people over at Thoughtbot. It provides a simple and intuitive CLI for interacting with Heroku apps.

To deploy an application to Heroku, you run the famous git push heroku master then run any pending migrations. Not too bad. But what if you could simply write production deploy? That’s what Parity gets you.

# before
git push heroku master
heroku run rake db:migrate --a your-production-app
# after
production deploy

The deploy command takes care of pushing code and running any pending migrations.

NOTE: There’s currently an open issue for adding support for skipping migrations on deploy (Issue #104).

Deploying a feature branch to staging

A feature of Parity I particularly appreciate is deploying to staging. When I’m working on a feature branch, I’m able to call staging deploy without paranoia that I have the right app specified or that I’m pushing the correct branch.

# before
git push -f staging my-feature-branch:master
# after
staging deploy

Parity automatically deploys the current branch to staging and will “force” the branch if needed (lib/parity/environment.rb). It just works.

Accessing the production console and tailing the logs

Both accessing the console and tailing can be done easily using the Heroku CLI, but the beauty of Parity is the consistency between commands.

Here is how you access the production console.

# before
heroku run rails console
# after
production console

And here is how you tail the production logs.

# before
heroku logs --tail
# after
production tail

Without Parity, deployments use Git with three arguments while accessing the console uses the Heroku CLI with three differently purposed arguments. That’s unnecessary mental gymnastics.

With Parity, you get the intuitive environment + action format for all commands. This simplicity makes it clear what you are trying to accomplishing and reduces typos.

Installing and configuring Parity

You can install Parity using Homebrew.

brew tap thoughtbot/formulae
brew install parity

Done. So what does this get you? Admittedly nothing without some config. To get Parity to work, you need to add a git remote for “production” and optionally another for “staging”.

heroku git:remote -r staging -a your-staging-app
heroku git:remote -r production -a your-production-app

That’s it! Welcome to Parity.