Continuous Integration has typically been a practice only performed by companies who want that piece of mind for their client software, but does it need to be like this? Travis CI is a continuous integration service for the open source community. We make testing OS projects dead simple and fun. But most importantly, we help improve code quality for large projects like Doctrine2 and symfony, to smaller libraries like FOSRest. The vision behind Travis CI is to become for builds what PEAR is for distributing libraries. In this talk Josh, one of the core members of the Travis CI team, will introduce you to the vision behind Travis, the how it is implemented, and why it matters to everyone in the OS community.

You can listen to this latest episode either by using the in-page player or by downloading the mp3. You can also subscribe to this podcast.

These days, good PHP object-oriented libraries are all around and easily available. To me, it is actually thrilling to be part of this flourishing community, while working with Symfony2 and blogging about the Framework, the Components and their neighbors (like Silex). [...] Still, to me, contributing felt like too big a step to take right now. Until a few weeks ago, when I was looking for something I needed (a PHP client for the Microsoft Translator API) and could not find a decent solution. I decided to make it myself, and share it online.

He shares his "checklist" of steps he followed to get the library up and working (less about the library and more about the process):

• Write the code
• Initialize a Git repository
• Add a composer.json file
• Add unit tests
• Make it open source and developer friendly
• Push your code to GitHub
• Register your project at packagist.org
• Register the Packagist Service Hook
• Versioning
• Continuous integration using Travis CI

He also suggests that, at least at the outset, you skip some of your tests that might rely on external data sources/resources (so the build can start as green on Travis) then coming back and refactoring to mock things out correctly. It might look like an intimidating list for a beginner, but it's a great process to follow to have a robust, effective development/deployment process.

Testing is important - most people understand that by now. A lot of people write tests for their open source code already, but in-house testing is still hard. [...] While I prefer to run my database tests against a SQLite in memory database, there are these edge cases, where I work with multiple database or I write a direct query (and by-pass the ORM-magic). In these cases I need to have that database server available in my test environment! The following blog posts explains how to solve these things with Travis-CI. I will walk you through the setup on Travis-CI's business service. But most of this applies to their open source offering as well.

He's broken it up into a few different steps - the setup and configuration of the ".travis.yml" file, adding in a "composer.json" file with the needed dependencies and the recommendation of a "phpunit.xml" in your project's root. He shows how to use Doctrine's "SchemaTool" utility to generate his schema off of the comments on his entities (instead of checking in SQL). This setup them gives him access to Doctrine's EntityManager object in his tests and he can go from there. If you're thinking about doing something similar, check Travis' list of supported databases before you do anything, just to be sure.

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.

He talks a bit about how it works - builds running on VMs, some with advanced tools like Selenium - and includes an example based off a simple travis.yml file defining a script to run pre-build. He also points out a special caveat about databases - they support things like MySQL, Sqlite, MongoDB and CouchDB, but you'll have to generate them from scratch every time, sample data and all.

To integrate your project with travis the only thing necesarry is to have a .travis.yml file and a working PHPUnit test setup like http://github.com/simplethings/SimpleThingsFormExtraBundle. Where the Tests/vendors.php script is executed before the tests are perfomed. But it would be way cooler to just have Composer handle the autoloading and dependencies.

A sample .travis.yml file is included in the post (also here) as well as instructions for grabbing dependencies and including the autoload process in your application's bootstrap.

Continuous integration is one of these topics that had a slow start, but in recent years has really taken off. The slow start is likely to be attributed to the fact that it was perceived as hard to setup and maintain. But solutions around Jenkins and Sismo are making it easier and easier. But thanks to the new Travis CI service, its now essentially so easy that there is no excuse not to use CI for PHP projects, at least if you are hosting your OSS code on github.com. What makes this service so crazy cool is that you can run your tests against multiple PHP versions, multiples databases (heck even RabbitMQ) and against multiple versions of various libraries.

Thanks to the "first class" PHP support they offer, setting up a PHP project is as simple as creating a ".travis.yml" file in your github-based project (including PHP versions to test against, dependency management and "before script" tasks to execute). If you're looking for a CI platform without a lot of the hassle involved in the usual setup, you'd do well to check out Travis CI.

You can also see another example of a project setup in this post from Travis Swicegood.