Heroku Continuous Deployment

A few weeks ago, we rolled out preliminary support for automatic code coverage collection and custom post-build tasks.

Over the coming weeks, we’re rolling out better UIs in front of these features, but if you’re impatient, and you’re up for using our sample rake task, read on for end-to-end continuous deployment.

I’ll describe how we use post-build tasks and environment variables to implement continuous deployment of one of our own apps into Heroku, including running migrations.

Note: If you currently use Tddium’s push-on-pass functionality, this approach replaces it.

Step 1: Setup Environment Variables

The first step is to set ephemeral environment variables in Tddium containing sensitive parameters, like your Heroku app name and credentials.

Tddium’s environment variables allow you to pass this sensitive information to your tests and the post-build hook that we’ll create – without having to check these in to your repository.

You can find your Heroku API key by logging in to your Heroku Account page.

Step 2: Install the Post Build Task

We’ve written up a sample post-build task that will push to Heroku automatically (gist). You can customize this task as you need. Over the next few weeks, we’ll be rolling out a more streamlined UI to make post-build configuration much simpler.

Step 3: Authorize Tddium’s Worker Key

Run tddium account to get the Tddium worker key you need to authorize with Heroku.
Save the key in a file: tddium-worker-key.pub.
Then run heroku keys:add tddium-worker-key.pub

Step 4: Trigger A Build

That’s it! Push to your git repo to trigger Tddium CI, or trigger a build manually on your Tddium Dashboard.

When the push and migration completes, you’ll see a post_build_hook.log.

If you haven’t configured Tddium CI, read our getting started guide for more information.

If you don’t yet have a Tddium account, sign up now for a free trial!

Don’t hesitate to contact us at support@tddium.com for more information.

Update (10/25/2012): 

Our awesome customers  have pointed out a few gotchas and solutions:

  1. Make sure you have the ‘heroku’ gem in your Gemfile, or the above Heroku commands won’t work.  We’ll soon be automatically including the heroku toolbelt in our workers, but until then…
  2. If you’re using Rails 3.1+ and the asset pipeline, make sure you enable the heroku user-env-compile labs feature.

Update (6/21/2013):

The Heroku toolbelt package has been installed in test VMs for some time now so it is safe to use instead of the gem.

Update (7/15/2013):

If you are using Ruby 2.0, you will need to use Bundler.with_clean_env to run the Heroku toolbelt command.


  • Miguel Madero June 20, 2013 at 6:24 am

    This was working, but seems like it broke with some of the latest changes.

    • William Josephson June 20, 2013 at 11:03 am

      Miguel, in your case it looks as though there is an authentication problem — i.e. you need to authorize the proper key in Heroku. Some users also have had excessively long running post-build hooks and the default timeout is now enforced.

      • Geoff Tidey (@GeoffTidey) June 21, 2013 at 12:20 pm

        Wiiliam, How do you increase the timeout duration?

        • William Josephson June 21, 2013 at 3:00 pm

          Geoff, there is a hard cap at the moment, but you can increase the timeout up to that cap by setting the {:tddium => {:timeout_hook => seconds } } (as YAML) in tddium.yml.

      • Dharampal H S June 26, 2013 at 9:22 am

        William, what’s the hard cap as of now?

        • William Josephson June 26, 2013 at 2:24 pm


          The hard cap is long enough that it should not pose a problem unless you are doing significant computation in the hook, which you really shouldn’t be doing. If you have trouble and are hitting the cap, please contact support for now. We’ll be improving the hook infrastructure and the associated documentation in the short term.

      • codemangler June 26, 2013 at 9:35 am

        What’s the hard cap on build hook timeouts as of now?

  • Geoff Tidey (@GeoffTidey) June 21, 2013 at 12:18 pm

    Couple of observations –

    1.) The post-build task link in the first paragraph is dead – http://docs.tddium.com/getting-started/post-build-tasks

    2.) It would be cool if you had one gist that contained the rake task in Step 2.) embedded in this page. Currently there are several on github, which is the official & most current? https://gist.github.com/search?q=tddium_post_build.rake
    Why not use revision history?

    • William Josephson June 21, 2013 at 2:58 pm

      Geoff — thanks for pointing out the broken link! We’ve fixed it. There is a link in the post to the current gist; we’ll be updating it.

  • James Stewart July 25, 2013 at 6:08 pm

    In a rails app where should the tddium_post_build.rake file go?

    • Jay Moorthi July 25, 2013 at 6:13 pm

      @James: If you commit it as $RAILS_ROOT/lib/tddium_post_build.rake, it should get picked up automatically.

      • James Stewart July 25, 2013 at 10:06 pm

        Thanks, also I get an error of no directory ‘credentials’ for the line:
        File.open(File.join(dir, “credentials”)

      • Justin Finkelstein September 23, 2013 at 12:44 pm

        If I’m not using a Rails app, where do I put this file and how do I reference it from tddium.yml, if this is necessary?

  • Nate R July 16, 2014 at 10:58 pm

2 Trackbacks

  • […] 5/2012: Read our latest blog post about Continuous Deployment for Heroku […]

  • By Tddium And New Relic « tddium on October 23, 2012 at 1:25 am

    […] Here’s an example of how to set up deploy notifications for a repo that’s already set up with Heroku, Tddium and NewRelic, and configured for Heroku auto-deployment using the procedure described in this earlier post. […]

Post a Comment