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?

Wysocki

I just took a look and it seems you can make a script to install heroku gem, and then have another script for on_sucess login and do git push heroku master. The details on this have no idea, and i'm just supposing it's possible – Shaped

yep! but how handle the ssh keys on travis-ci? – Wysocki

I think that one of the answers below deserves an accept, @danielgatis. I used information in both @Odi and @Marius Butuc's answers to get my continuous deployments going. I will add for reference here that because I use gems that require me to set config.assets.initialize_on_precompile = true in application.rb, I usually had to precompile my assets before doing a manual deployment to Heroku. After running $ heroku labs:enable user-env-compile -a YOUR_HEROKU_APP, I didn't need to run rake assets:precompile in my .travis.yml. I just hope Heroku keep this functionality. – Cabrilla

Also, for the reference of others, if you're running a test suite and want only to deploy to Heroku if the test suite passes (and not if it fails), change after_script above to after_success in the answers below. – Cabrilla

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/

Strong

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

Colic

You should change after_script to after_success or risk deploying code which is broken. – Flawy

I ended up using this except instead of doing a keys:clear I added this at the end: - for i in $(grep '[^\ ]*$' ~/.ssh/id_rsa.pub -o); do heroku keys:remove $i;done Which should simply remove the newly added key and nothing else. Meaning if you use this account for local development you don't have to keep adding you key for every deploy. – Besse

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 [email protected]: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.

Contiguous

what can I do to my build to supply what its asking for? when Travis parse my .travis.yml and gets to heroku keys:clear, i see to following code and I dont know how to supply the email heroku-cli: Installing CLI... 22.44MB/22.44MB Enter your Heroku credentials. Email: – Laborsaving

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.

Fimble