Lets take a look at using Travis-CI for continuous integration specifically to track the build status for our node projects on GitHub.
If you aren’t familiar with the concept of Continuous Integration it’s basically the idea of having a server that is always running the latest version of your code ensuring that its always working. Whenever you push any changes to your master branch (i.e. production code) the server will make sure your code is actually production ready – i.e. run your build process and tests and ensure they pass etc). Using a system like this will ensure that your actual deployments to production can happen with confidence and without any fear – allowing you to release more regularly!
Here is a link to the latest build of the BENM repo I maintain:
https://travis-ci.org/jkat98/benm
Travis is a terrific free service to act as a CI for your GitHub projects. It’s super easy to get setup and running and you even get those fancy green/red build status badges you can post on your README.md file in your repo!
The first thing you need to do is goto travis-ci.org and register with your GitHub account. You’ll obviously need to activate Travis through GitHub to give it permission to read your repos. Once connected, Travis will display a list of all of your repos and you can toggle those that you want it to regularly to build.
Once you toggle the off switch to on for your particular project, you need to then add a .travis.yml file to configure the project and any build steps necessary. For our particular needs, we will be adding Travis support for the BENM repo which is basically a node.js project that uses Grunt for various build steps. Heres the .travis.yml file:
[sourcecode]
language: node_js
node_js:
– “0.10”
services:
– mongodb
before_install: npm install -g grunt-cli phantomjs
install: npm install
before_script: grunt init:dev build:dev
[/sourcecode]
A few key points to notice in the code above is that we are including a before_install command to make sure we actually have grunt-cli available to us as well as PhantomJS since we use that for our client tests. Then we make sure all of our node modules are installed with a simple npm install (although I believe for node projects Travis does this automatically anyway). Also note that we list mongodb as a service that is required (although this too is probably not necessary since our build and tests don’t actually rely on mongodb). The before_script flag is where we indicate our actual build command (note its important for us to include init:dev since the repo is pulled down fresh every time a build is triggered.).
Another important configuration step we need is to ensure that the package.json file for the project has the correct start and test commands configured:
[sourcecode]
“scripts”: {
“start”: “node server/server.js”,
“test”: “grunt test”
},
[/sourcecode]
What you don’t see from the original .travis.yml file is that Travis will use “npm test” by default on a node project.
Finally the last step required to actually trigger the build in Travis is to push a commit to master. What better way than to commit the changes we just made!
[sourcecode]
$ git commit -a -m “Configure Travis-CI”
$ git push origin master
[/sourcecode]
Switch over to Travis and you should see (maybe after some delay) the build start. You can monitor the log and watch it do a full npm install, output your grunt init:dev and build:dev commands, and finally the output for the tests. In the end, assuming everything builds and tests pass you should get a green dot for your build and the badge in the upper right corner should be green and “passing”!
Last step is to edit your README.md file and include the badge image. Just click the badge icon on Travis and it will popup a dialog that has a number of different options for the image file. The easiest is to grab the Markdown version and paste that in your README.md file for GitHub.