Grails, Heroku and Travis CI — Continuous Deployment into the Cloud

Jenkins does a lot of stuff well, and a lot of stuff…not so well. Let’s try Travis CI

When starting this new Grails project, I thought i’d make the switch over to Git (after SVN usage for as long as I can remember).

I started to implement Jenkins as a CI system for the project, but ended up bashing my head against a wall getting it to play nicely with my GitHub repo, setting up post commit hooks, etc.

I was then recommended Travis CI by a former colleague and even after using Jenkins/Hudson for the better part of the last decade, I am entirely sold.

The reason i’m sold is that within 45 minutes of looking at the Travis site, I had a CI system that picked up commits to my dev and master branches, worked out which of my Heroku applications to deploy to, ran all my unit tests and pushed the code out to the appropriate server. Pushes to my dev branch get pushed out to my staging environment, Pushes to the master branch get pushed to live. Any test or build errors cause a build to fail, and I get an email alert as to the cause

That’s basically everything I want a CI/CD implementation to do, and Travis CI made it trivially easy to get that set up and start getting on with my actual job.

I’m going to write this as a very quick write-up on the process of getting Travis, grails and Heroku playing nicely together, in case anyone is curious.

1. Register an account with Travis CI and link the account to your GitHub account

(Not much to cover here — if you’re using a private GitHub repo, you need to pay for a premium Travis account though. Our current package sets us back $129/month) — but there is a free trial period with a set number of builds.

1. Run grails wrapper on your project

The Grails Wrapper will be used for running Grails Commands. As a matter of preference, I tend to run chmod +x on the grailsw script that gets generated, in case of permission errors when other systems use the script)

2. In the root of your Grails application, create a YML file called “.travis.yml” (note the initial full stop).

The .travis.yml will be picked up by Travis CI whenever you push to your repo, to tell Travis what to do with the pushed codebase.

My .travis.yml looks like so:

language: groovy

jdk:

— oraclejdk7

before_script:

— chmod +x grailsw

script: ./grailsw clean

&& ./grailsw refresh-dependencies

&& ./grailsw “test-app unit:”

before_deploy:

— chmod +x grailsw

deploy:

provider: heroku

app:

master: <MY LIVE HEROKU APP NAME>

dev: <MY STAGING HEROKU APP NAME>

api_key: <MY HEROKU API KEY>

Hopefully most of that’s fairly self explanatory.

1. The YML is telling Travis to first ‘chmod +x’ the grailsw script (Travis will use the Grails Wrapper to run grails commands, but it needs to be executable within Travis’s build environment) The ‘before_script’ entry tells Travis to do this before any other commands are run.

2. Travis then uses grailsw to run “refresh-dependencies” and “test-app unit”. Naturally, you can extend this as far as you want.

3. Next, the ‘heroku’ provider setting tells Travis that it will be deploying to Heroku. I have two settings under ‘app’, each of which corresponds to a different branch of my GitHub repo, with an assigned Heroku app name. This tells Travis ‘for push to branch X, deploy to heroku app Y’

That’s it

Push to your branch and you should see Travis pick up the push and start running your build process! Hooray, you’re now a DevOps engineer!