Travis-CI - Continuous Integration Server

Travis-CI is hosted continuous integration server for Github projects. The continuous integration part is fairly standard: it runs unit tests and report results after each project change.

The hosting part is unusual: the service runs tests on their own infrastructure and provides access to test results. The user does not need his own hardware nor to install and run the server. All that is part of the service.

Any public repository hosted on Github can use Travis-CI for free. Private repositories have to pay and the Travis Pro version they get is a bit different from the regular one.

This post is mainly about the free version. First chapter describes what Travis-CI does. Second part contains few things about Travis-CI server, infrastructure and organization behind it. Mini review with our experiences is located in the last chapter.

Features

Travis-CI is continuous integration server and nothing else. It builds the project, runs tests and shows tests results in multiple ways. It has some limitations listed in a last sub-chapter, but they should not matter much for most open source projects.

Basics

The service is integrated with Github and you must host your project on Github if you want to use it. Once configured, Github sends notifications about every repository change to Travis.

Sign up and configuration are pretty straightforward and explained in the getting started document.

Each time there is a change in any branch of the project, Travis-CI will:

• initialize a clean virtual machine with Ubuntu Linux,
• clone project repository from Github,
• configure the machine,
• build changed branch of the project,
• run tests,
• report test results.

In addition, Travis-CI automatically merges and tests all incoming pull requests. Tests results of pull requests are integrated into Github GUI. This feature is quite impressive, because you know whether the new code breaks your build without having to merge and test it manually.

Test Results

All test results of all public repositories are public. This is probably the main difference against the Travis Pro version. Tests results of private repositories are never published.

Tests results are available in four different ways:

• email,
• web page,
• status image,
• json API.

Email

Email is sent to the repository owner whenever build fails. It is sent also in case of virtual machine error and when the build starts working again after previous fails.

Web Page

Each repository has its own page with list of builds, status of each build and console output of each used virtual machine. You can try less4j test results page to see how it looks like.

Full console output turned out to be especially useful. Our project behaved differently on Travis-CI environment and we could turn on logging and see everything that was going on. Debugging is much easier if you do not have to guess and can see any information you want.

Status Image

Status image represents last tests result of the project or specified branch. It is green when the build passed, red if it failed and grey if it is still running. You can add it to your project site, readme file or any other web page.

Current status image of Less4j: .

Json API

Finally, you can fetch test results through public API.

Limitations

Due to limited computing time, build time of each project is limited to 20 minutes. In addition, tests are not necessary performed immediately. Requests wait in queue until Travis finds free resources to perform them.

Under the Hood

This chapter contains information about Travis-CI infrastructure and organization behind it. If you are not interested, skip to the next chapter.

Software

The software running on the server was written in ruby and is open source. Its source code is published on Travis-CI Github account. The core repository has the same name - Travis-CI.

It was designed as a distributed testing service for huge number of projects, builds, pull requests, branches and so on. Running it locally for a small number of projects seems like a huge overkill, but you can do it if you want.

Technical overview is a part of Travis-CI repository readme. In addition, both local configuration and Travis-CI architecture are explained in this blog post.

Hardware

Hosted server runs partly on Heroku and partly on members infrastructure.

Organization and Funding

Although Travis-CI documentation does pretty good job with technical information, finding out who they are and how they are funded was a bit harder. This was weird, because hosting and organizing such service must costs a lot of effort and money.

Anyway, the information is on Travis-CI donations page. Scroll down to FAQ on the bottom and all is written there. The project started a German company Travis CI GmbH in Berlin and lives mostly out of donations, founders money and from what they earn on Travis Pro.

The same page contains also future plans and does a bit of show about donations. In short, if you donate, they will send you stickers, ringtones, personal thanks and so on. More importantly, you can get also discounts on future Travis-Pro features.

Experiences

We setted up Travis-CI a few days ago, so our experiences are quite short. Travis-CI turned out to be very easy to use. Its documentation is easy to read and console output very practical. Project configuration have been straightforward without any problems.

Tests have been performed withing few minutes most of the time. However, we have seen also a slow day, when it took few hours to run the test. At one point, Travis-CI started to ignore our project changes. The problem was fixed after we forced build from Github administration page.

Overall, results are very good. We assume that response to private repositories is going to be a bit faster, simply because they are paid.