How to deploy an rails app on heroku from travis-ci?

Question

There is any way to deploy a heroku rails app after a travis-ci success build?

Answer 1

Travis CI now has built-in support for deploying to Heroku: http://about.travis-ci.org/blog/2013-07-09-introducing-continuous-deployment-to-heroku/

Answer 2

I just implemented this case with an application of mine. It's actually not that hard to do, but it requires some steps:

1. You need your heroku API key
2. See this gist for an example .travis.yml and get the travis_deployer.rb script
3. Then install the travis gem, see the answer to another question on how to secure your API key.
   • If you don't care about it, just use the example from gist above.
   • Run travis encrypt your_username/your_repo HEROKU_API_KEY=<your key here>
   • Copy the result in your .travis.yml in the env -> global section

The travis_deployer.rb file takes care of the ssh keys and the remote branch for heroku.

If you've performed all these steps you .travis.yml might look like this:

env:
  global:
    - secure: "1u21hjnmHjkghduUIJhhs76saljlkajdlfhGhgdJgfaVtgasfLLmNBnb87dad="

after_success:
  - gem install heroku
  - yes | ruby travis_deployer.rb
  - heroku keys:clear
  - yes | heroku keys:add
  - git push heroku master

Answer 3

Here is a version I found on Mark Bates' blog. It's similar to Odi's, just that it relies on the after_script in your .travis.yml file alone.

1. First of all, use Travis' feature to encrypt environment variables so your secret API keys remain protected:

   gem install travis
   travis encrypt username/repository HEROKU_API_KEY=YOUR_HEROKU_API_KEY
   

2. Then append the following to your .travis.yml file:

   env:
     global:
       - secure: YOUR_SECURED_HEROKU_API_KEY
   after_script:
     # Install the Heroku gem (or the Heroku toolbelt)
     - gem install heroku
     # Add your Heroku git repo:
     - git remote add heroku git@heroku.com:YOUR_HEROKU_APP.git
     # Turn off warnings about SSH keys:
     - echo "Host heroku.com" >> ~/.ssh/config
     - echo "   StrictHostKeyChecking no" >> ~/.ssh/config
     - echo "   CheckHostIP no" >> ~/.ssh/config
     - echo "   UserKnownHostsFile=/dev/null" >> ~/.ssh/config
     # Clear your current Heroku SSH keys:
     - heroku keys:clear
     # Add a new SSH key to Heroku
     - yes | heroku keys:add
     # Push to Heroku!
     - yes | git push heroku master
   

3. And you're done: commit your new changes and enjoy deploying to Heroku via TravisCI.

---

Edit: If you get any errors on travis encrypt, this might be your solution.

Answer 4

I had just been thinking of this kind of scenario, though I didn't specifically consider Heroku as the platform of choise. Anyhow, this is what I have come-up with:

1. Pull requests go to "development" branch
2. Travis test the pull request for you
3. If we are about to deploy what's currently in "develop" - humans pull request, review and merge that into "release/candidate" branch
4. Travis tests again once merged
5. Once test on that branch passed - get Travis to create a pull request targeting "release/production" (perhaps write a wrapper for GitHub API for creating the actual pull request form Travis).
6. Depending on whether we actually want to deploy or not quite yet - a human merges (into "release/production") or closes the pull request created from Travis
7. Have either a deployer host or have each of the app hosts (if you have many and don't want to have an SPF) to track the "release/production" branch.

I'm sure you could implement a Heroku app that will handle the role of being the deployer host or something even more crazy.

Also, you may wish to try having Travis to notify you via IRC and have another IRC bot on your client side which will have access to you personal SSH key and make a push to Heroku, you could also implement a confirmation interface there by means of having a private conversation with your own bot or scripted GUI interface with a "Go ahead!" button. If you are not so old-school, you can use Hubot for that purpose.

By the way, you could also introduce some sort of staging branch or whatever you like in between some of the above steps. You probably should also use tags and the rollback would just pushing a know working tag into "release/production" from where it'll be picked up by your deployer script.