Software development

Tech Pick of the Week: Travis-CI

continuous deployment, Continuous integration, Tech Pick of the Week, travis-ci

Using Continuous Integration is like good eating habits. Everyone knows how, when and why, but still it’s easier to start next week. Or month. Or maybe sometimes later. Fortunately, like with most other problems, the Internet has a good solution for this particular one. Enter Travis-CI. Travis provides hosted CI, so there is no need to have a bunch of dedicated servers hanging around somewhere. It has very easy integration with Github repositories, so setting it up requires only a few minutes of work, for any of the first class citizens. After setup Travis can automatically build all branches and all pull requests for the given repository. Travis has some addons available, so you could e.g. run Selenium tests as part of your build. It also supports continuous deployment to Heroku, Nodejitsu or NPM, among others, so it’s possible to implement the whole application release lifecycle through the service. Travis has already been around for a while for open source projects. Nodejitsu started using it already in 2011, and we’ve successfully used it with Tantalum, an OSS project of ours. Actually you have probably run into Travis on Github, since many prominent open source projects already use it. Some of the most notable are Ruby on Rails, ember.js and jquery. The best thing? All of this is completely free (as in gratis) for all open source projects. Although Travis has been branded as Continuous Integration for the Open Source Community, Travis is not only meant for open source projects. There is also a Pro service available, which is meant for all non-public projects. It’s possible to use it with private commercial/company repositories as long as you have the code in Github. Unlike the OSS counterpart, the pro package does come with a monthly subscription fee. There are a number of different packages, which differ in the number of concurrent builds you are allowed to run. Whether or not the price is too high depends your usage. At least having a limited number of executors is bound to make you optimize build times, since having a long running build will prevent other builds from being executed. Travis already supports a lot of different platforms and frameworks, and since the service is in active development, new features are constantly being added. The most interesting one is probably the support for builds on OS X. This means that running a build for an iOS or OS X project is possible on Travis. This is something of an actual competitive edge, as maintaining multiple different host environments in-house can be cumbersome. Unfortunately Windows is still missing from the list of supported platforms, although rumor has it that support is to be added at some point. It is still possible to build C# projects, but not without extra effort. There are some caveats with Travis. The biggest one is probably that there is no out-of-the-box way to get hold of the build artifacts. Travis stores the build logs, but if you generate other reports, like a unit test coverage report, those will have to be uploaded to some other location after the build. The default and only integration is to Amazon S3, which of course requires a separate account on Amazon. Artifacts could also be deployed using the deploy functionality, but it still requires some extra effort to make it happen. Having external integrations also requires the user to store some credentials in the repository, which might not be an acceptable solution for you, even if they’re encrypted. Another caveat to note is that Travis build boxes are transient, so you'll get a fresh environment for every build, and the environment gets discarded after the build. This may or may not be a problem, but if you have a really big repository or large dependencies they need to be downloaded for each and every build. This overhead could be significant, if you're on tight turn around time, or have a pro package with a limited number of concurrent builds available. So, how does Travis compare to Jenkins, the de-facto standard in CI? Jenkins is more versatile and allows more custom configuration. There’s also an abundance of more or less useful plugins for Jenkins, which allow changing almost every aspect of the tool and your builds. On the other hand, getting your initial build to run in a Jenkins installation, even a hosted one, is significantly more cumbersome than with Travis. Setting up a complex custom build process is going to be easier using your own Jenkins-server compared to Travis. However, as more and more new features are added to Travis, this gap is only going to shrink, assuming that you’re using the provided tools and integrations. Travis is a really easy-to-use alternative for that old Jenkins server farm you might have hanging around in your data center. Different development platforms and super easy setup really make a difference and make CI more fun. If you’d prefer to use something else than Travis, there are a whole array of alternatives to choose from. Not having a CI is nowadays mostly a poor excuse, given the abundance of good tools and services available.

Travis is our Tech Pick of the Week, but it’s by no means the only hosted CI provider out there. Alternatives include at least

If you have more, then please feel free to notify me on e.g.


. We’re always looking to improve our own ways of working, so hearing about experiences using any of these is also highly appreciated.