Travis CI : Continuous Integration Made Easy

This weekend I spent some time improving the structure of some of my open source projects repositories and also finally decided to add a Travis-ci hook to the most active/newest ones.

Travis is a free continuous integration server for open source projects that can be used to automate tests and help you deal with projects that have multiple contributors. If you are familiar with GitHub you probably seen their build status icons on a few projects before (on the image above). It can be used to test multiple languages like JavaScript, PHP, Python, Ruby, Java and many others. It also have options to notify the project maintainers every time the build status changes or on each commit. (email, IRC, campfire, etc)

It is really easy to setup it if your tests are already executed on the command line. If the tests needs a browser to work you can hook a headless browser like PhantomJS. - For my projects I’m just executing the tests on node.js for now since that should be enough to catch most errors. - Having a headless browser can help to double check if the code works on multiple environments.

Travis documentation is very clear and the amount of boilerplate is minimal, for a regular node.js project you just need a file named .travis.yml on the root folder containing:

 language: node_js
 node_js: 0.8

By default it will execute the npm test script for node.js projects. If you want/need you can execute multiple scripts like:

   - "echo Travis rocks"
   - "node build"
   - "npm test"

On amd-utils I added a pretest script that checks if all modules have specs (if it can’t find it will create a failing spec for the module) and update all packages/spec runner. I also added a script to check the code coverage of my tests (using Istanbul) to make sure pull requests (and my own commits) have a high code coverage.

   - "npm test --coverage"
   - "node ./node_modules/.bin/istanbul check-coverage --statements 90 --branches 90 --lines 90 --functions 90"

With the code above the integration test will fail if the code coverage is below 90%. This will ensure we have tests for every method and will help check if our tests are covering different scenarios - code coverage is just a metric to help you identify potential problems, it doesn’t really mean your tests are good enough, it just identify if the statement/line/function/branch was executed at least once, so beware, don’t trust it blindly. - I’m not setting the code coverage higher since amd-utils have some specific code branches that are only executed on old JS engines (specially IE). Check the last build report.

Travis is nicely integrated with Github, showing if a pull request passes the CI test, it is a good way to spot errors early.

The build status icon is also a nice indicator to add to the project README.md file.

I highly recommend it for projects with multiple contributors, will be using it on all open source projects from now on.

Automate repetitive tasks and make contribution easier, it will surely pay off in the long run.

Further Reading


Leave a Comment

Please post only comments that will add value to the content of this page. Please read the about page to understand the objective of this blog and the way I think about it. Thanks.

Comments are parsed as Markdown and you can use basic HTML tags (a, blockquote, cite, code, del, em, strong) but some code may be striped if not escaped (specially PHP and HTML tags that aren't on the list). Line and paragraph breaks automatic. Code blocks should be indented with 4 spaces.