Heroku developer setup

Install the Heroku Command Line Interface (CLI).

Now, in the git clone working copy of our scihist-digicoll project, set up your heroku remotes, by running these commands:

1. add production: heroku git:remote -a scihist-digicoll-production -r production

2. add staging: heroku git:remote -a scihist-digicoll-staging -r staging

3. set staging as default: git config heroku.remote staging

Running heroku commands

Now, when you run heroku commands from inside the project working directory, our staging app is the default, but you can use the -r production command to target the production app. Eg:

heroku ps (staging)
heroku ps -r staging (same as leaving off the -r flag)
heroku ps -r production (production)

These use the “remotes” set up in your git working copy in the previous section to refer to the heroku apps. If you want to run heroku commands from somewhere other than a working copy set up with heroku remotes, you can always use the -a / --app flag specifying the full app name instead. (You can choose to run these from inside the git project working directory too).

heroku ps -a scihist-digicoll-production
`heroku ps -a scihist-digicoll-staging`

Pushing code to to heroku

Standard heroku instructions apply, except since we have two remotes — one for production and one for staging — named accordingly, we use those names to push:

• from master branch:

  • git push -f staging

  • git push -f production

• another branch:

  • git push -f staging some_other_branch:master

  • git push -f production some-other_branch:master

Note: it’s normal to use the -f (force) flag with pushes to heroku, even though ordinarily with git this can be a dangerous operation. The heroku docs say:

The -f (force flag) is recommended in order to avoid conflicts with other developers’ pushes. Since you are not using Git for your revision control, but as a transport only, using the force flag is a reasonable practice.