Migrating to Travis-CI from Bamboo

At work we have been using Bamboo for a little over a year. It has served us well in the past, but for our newest project it has just not be working well. The cloud version seems to be severely limited.

Want to upload your app to AWS after it's built? Yes, there is a plugin for that but it does not support Bamboo cloud. Headless browser testing? Well it is possible, but you have to configure your own EC2 instances.

Bamboo just does not seem to be moving forward. As a tool it was starting to get in our way. We decided it was time for our team to try something new.

I've been looking for a opportunity to give Travis-CI a try. Travis-CI builds over 200,000 project and has over 100,000 users. They must be onto something. It almost feels like every GitHub project is building with Travis-CI.

In less than a few hours we migrated to Travis-CI. It was quick and painless.

How we migrated

Unlike Bamboo, Travis-CI keeps the build configuration in your project. .travis.yml is where all the magic happens. This file controls everything.

Step 1: Create an account

You of course have to set an account with Travis-CI. They use your GitHub credentials to login. Then just enable your repository in Travis-CI: https://travis-ci.com/getting_started

Step 2: Building

To have your project build you first need to add a .travis.yml. Our project is Java 8/Gradle so the initial file looked like this:

Step 3: Migrating status scripts

I wrote some status scripts that I covered in a previous blog post. I won't go into their functional details here, but I will cover the migration changes.

Travis-CI also lets you run scripts. These scripts have to be part of the repository. This is a really good idea, build scripts are code and all code should be in your repository. I added the script to our project under src/main/scripts/post-build.sh. I had to replace the Bamboo variables with their Travis-CI equivalents.

All we have to do now is tell Travis-CI to call this script after the build. This is done with the after_success setting.

That's all it took. Six lines of configuration and moving our post build scripts.

Future topics

Setting up the new build took so little time that I ended up setting up a few extras:

1. Coveralls coverage reporting.
2. Slack Notifications for Travis builds.
3. Automatic deployment of our builds to Amazon Elastic Beanstalk.

I'll cover those three and headless browser testing in a future post!