TravisCI Intro and PHP Example

Travis CI is a distributed Continuous Integration system, initially available as an open source project. A Pro version will be available for closed source projects in the future, in a model similar to Github's.

Travis CI in fact works by tying itself to a particular project on Github, and by triggering a new build every time new commits are available on the chosen branch (master, usually). Your build shows up on the main page along with all the other projects in the newsfeed, so try to maintain it green. :) Travis CI adds this other aspect to Github's social coding.

The supported languages vary from Java, Scala, Ruby, PHP... There is a lot of support as for example multiple versions of each interpreter are available.

How it works

Although I'm not an expert in cloud-based builds, here's what I understood by reading my logs and paying attention to the behavior of the builds on Travis CI:

1. Builds run on virtual machines, provisioned for that specific job. There is no shared state leftover from the previous build, or from another project as you can even install system-wide packages. This also means that you'll have to download with wget your own tools (in my case a Selenium jar).
2. The virtual machines come with support for advanced tools like Selenium Server, which in this server environment runs over XVFB.
3. Builds are triggered everytime you make a push to your Github's repository, but if multiple commits are contained only the most recent one is considered, to save time.
   

PHP example

I set up, some months ago, a few Travis CI builds for the open source project I took over, PHPUnit_Selenium. Travis CI supports PHP 5.2, 5.3 and 5.4; I only used PHP 5.3 for a time but now I also have a parallel 5.2 build which does not cost me time. You may also want to run the test suite against all of the versions.

Speaking about configuration, here's my .travis.yml file.

language: php
php:
  - 5.2
  - 5.3
before_script: ./before_script.sh
script: "php run-phpunit.php"

script by default is phpunit, so you may not need to specify it. PHPUnit also has a phpunit.xml which can contain configuration for the build better than a string in this file.
My *before_script* checks out dependencies (as git submodules), and sets up some tools I need to run Selenium tests (namely a web server for a certain folder). Yours will probably be simpler:

git submodule init
git submodule update
cd selenium-1-tests
python -m SimpleHTTPServer 8080 > /dev/null 2>&1 &
cd ..
sh -e /etc/init.d/xvfb start
export DISPLAY=:99.0
wget http://selenium.googlecode.com/files/selenium-server-standalone-2.15.0.jar
java -jar selenium-server-standalone-2.15.0.jar > /dev/null 2>&1 &
sleep 30  # to wait for Selenium to be up and running

I use the & to run Selenium and the webserver in the background, since the before_script must return for the tests to start.

Databases

A special note goes to databases, which will be necessary if you're testing an application instead of a library like me. Travis CI supports both relational data stores (MySQL, PostgreSQL, Sqlite) and non-relational ones like MongoDB, CouchDB and others.

All these databases are available on 127.0.0.1, but since they start form a clean slate you will have to create a test database yourself via the command line tools (mysql, mongodb, ...) in your before_script. The documentation covers all the credentials and one-liners you'll need to get a new database up-and-running for your build (while it remains legitimate to share the database during the build with some teardown strategy that cleans up the instance, especially in the relational case.)

Conclusions

CI is like testing: doing it does not only provide the benefit of knowing everything works, but also the side-effect of a better architecture. In my case, it was providing everything needed for contributing to PHPUnit_Selenium in the repository, like the definitions of each dependency on the other phpunit packages; I rmember starting out with this existing project as it was difficult to retrieve all the info for building it.

Moreover, from the performance point of view it was also interesting to outsource long builds to an external machine. Although build times are now comparable after adopting XVFB on my developer machine, having Travis CI check for regressions after each push, no matter how small, is a robust safety net.

Show your green build to the world!