Ryan Angilly

My final gripe w/ Heroku has been solved: Release Management

Anyone that has maintained a “fer realz” web app knows that the release management is nothing to be taken lightly.

The common workflow for deploying goes something like this:

1. Qualify that master is ready to be deployed
2. Cut a release branch from master
3. Deploy that branch to production

Days and weeks will go by, and you will continue to advance master with new feature and bug fixes.  If a critical bug is found in production, the process to fix is simple:

1. Put the fix in master & verify
2. Cherry pick that commit into the release branch
3. Re-deploy release branch to production

Everybody wins.  You get to fix production without pulling your new and possibly not ready features from master into the fold.

In Heroku, you just push your git repo to their remote, and they deploy your app.  When pushing to Heroku, they will deploy whatever is on the master branch.

Sounds great, but the classic release management process breaks if you have a staging app also running on Heroku, because they both want to deploy off of master.  For example:

1. Deploy master to production
2. Build new features in a dev branch
3. Merge them to master so that you can deploy to staging
4. Find critical bug in production
5. …?

The problem here is that master is now littered w/ the features that are on staging.  What’s a guy to do?

Well, one my favorite humans (who apparently knows git better than I do) not only figured it out, but wrapped it up in a little Rake script for all our benefit.

Michael Dwan wrote this blog almost a year ago, where he solves the problem of release management in Heroku.  At it’s core, it’s just a git trick.  Instead of:

git push staging # <— staging is your heroku staging remote

git push heroku # <— heroku is your heroku production remote

Michael figured this out:

git push staging +edge:master #<— where edge is some local branch

The +edge:master part says “Hey, staging, I’m gonna trick you into thinking that the branch called edge is really master, so use that instead.”

Now you can pick a production and a staging branch, use any other branch (including master) however you want, and not worry about being stuck in a situation where you cannot fix a critical production bug.

He wrapped all this up in a handy set of rake tasks and even put some provisions in place to prevent you from accidentally deploying the incorrect branch to production.

Brilliant.  Thanks Michael.  You rock.