And now, a bit MORE Heroku confusion!

   Yes, I wrote earlier on how to have a lack of confusion on Heroku.  But sometimes, things can still be a little confusing.  I recently decided to play with Ruby 2, Rails 4, and a new app idea, all at the same time, via Heroku, launching Pull Request Roulette.

   All went well in development mode, trying it out on my own box.  Likewise in test mode, where I was trying to follow fairly strict BDD and TDD.  In production mode, though, and only in production mode (where it was most embarrassing and troublesome, of course), the "Take" feature, whereby someone commits to review a Github "pull request", wasn't working.  It was acting like I was trying to view the record of the pull request, which (at this stage) consists only of the URL.  It's all the worse because there are only two basic features, Submit and Take.

   Production mode on my own machine... showed the same symptoms.  Aha!, I thought, at least it's not Heroku-specific.  Tracking down Heroku problems can be a pain, due to the layer of indirection.  The logs (more easily accessible on my own machine) pointed to an asset problem.  Heroku precompiles on upload (unless disabled of course), so that wasn't it.  What could it possibly be?

   I Googled a gaggle, and it didn't bring me much giggles, especially after spending enough hours to develop late-night-goggles.  Finally I stumbled across a post on StackOverflow that referenced Heroku's documentation about Getting Started with Rails 4.x on Heroku.  I could have sworn that I had read that, and followed all its advice when setting up Pull Request Roulette initially... but the referenced Heroku's instructions to include some gems that didn't sound familiar.

   Sure enough, when I opened up the Gemfile, they were nowhere to be seen.  Adding them fixed the problem.

   So now, if you want to have someone review a pull request you've put together for an open-source project on Github, someone can now commit to review it.  For now, though, you won't know who it was, and there will be no record.  Want to add that feature to the project?  Fork it and create a pull request... and you can submit that one to Pull Request Roulette.

Even LESS Heroku confusion!

   Way back when, I wrote about easily using Heroku for both staging and production versions of your web site, without much confusion over which was the just plain "heroku" remote, by explicitly designating them as "staging" or "production" instead.

   Now, to make it even simpler, I've written a tiny little script, that lets me just do "script/deploy staging" or "script/deploy production".  Another advantage of using a script is that I can do additional mundane overhead tasks in there.  In this case, I turn Heroku's maintenance mode on before pushing, and off afterward.

#! /bin/sh

APP=codosaurus
BRANCH=master

SITE=$1

if [ -z "$SITE" ] ; then
  echo "Must specify site (staging, production, etc.)"
  exit 1
fi

heroku maintenance:on --app $APP-$SITE
git push $SITE $BRANCH
heroku maintenance:off --app $APP-$SITE

   To adapt it to your own site, simply adjust the APP and, if needed, BRANCH vars.  (If you want to get fancier and deploy the master branch to the production remote and the develop branch to the staging remote, that's a whole 'nother story... but should be pretty trivial to code up.)