Continuous integration lately became one of the essential parts of the application lifecycle. It is especially valuable for commercial projects as in such projects it is extremely important to make an update and deployment in time and to make sure that there was no regression and many other checks. This article start a series of articles on continuous integration, but despite the wholesale throw pillows of the commercial stability described above, the topic of this article is Travis CI, main feature of which is free support of open-source projects. To be honest, if we consider CI as a way of checking the stability of a program and not touch the side of a Continuous Deployment, I use CI for my side open-source projects far more often than for enterprise projects I work on. There are several logical reasons for this: the structure of a library is more conservative and it always suggest a programmer certain API, you expect the way one will use your library and it makes you easier to test your project. The second reason is that you fill responsibility as you know that someone will rely on your implementation and you want it to work perfectly. But the main reason is the existence of such a perfect solution as Travis CI. Travis suggests a cloud-hosted solution, so it’s extremely easy to start using it. Unfortunately it supports only Github integration (users are asking for a BitBucket support for almost 2 years), but still Github is de facto a place for an open-source stuff, so there’s not a lot to worry about. After logging in with Github account you will have possibility to choose the repository you wish to integrate: 
This will automatically add a service to the repository, which got Travis integration, you may check it on the settings screen of the repository: 
Now you have everything ready, so Github events will be captured by Travis and it will try to perform some actions on push, though they will be useless until you add the .travis.yml file to the root of your projects. It is YAML file containing build configuration, which is in the simplest case just language of the project and the list of versions of the platform on which you want build to be performed:
language: go
go:
- 1.0
- 1.1
I personally mostly hack on Node.js projects, among them there are several grunt plugins so the whole testing pipeline is built in terms of Grunt build system. Here is the common configuration:
language: node_js
script: "npm test"
node_js:
- "0.10"
- "0.8"
before_script:
- npm install -g grunt-cli
The most important line of configuration here is before_script, which will install grunt-cli as otherwise the build will not be done. One more nice feature suggested by Travis is link to the image indicating build status: 
Such images are often inserted to the readme of the project so that users, which are going to use the project, can be sure that it is stable. Travis makes the continuous integration painless and the fact that you don’t need to host it on your server should encourage you to use CI for majority of your projects.
