For those not familiar with the concept of Continuous Integration, I can sum it up with one very glib phrase: it lets you break your code before you buy it. [...] If I were to design a Continuous Integration (hereafter referred to as CI) system, what would it look like?

His requirements include version control integration, easy unit test execution, a web interface and be able to automate it all at a moment's notice. He talks about the importance of unit testing in CI and the tools that are available for the job like phpUnderControl, Xinc and Hudson. He also looks at the build process, from check-in through a successful build result and how he handles bugs when they do pop up.

Some of the most important tools for quality assurance in PHP projects are PHP_Depend and PhpUnderControl. In the future Qafoo - passion for software quality will provide support for both.

He talks a bit about each tool and how they should be used to find and treat a lot of the issues that could come up in your application development. Since the author of the PHP_Depend tool, Manuel Pichler, works for the company, they'll be supporting it as well as offering services for integrating it into your workflow.

In this blog post I'll try to explain how you can setup phpUnderControl and CruiseControl. This guide is mostly focused on getting phpUnderControl to work on a Gentoo Linux system, so some things are OS specific.

You'll already need to have PHP up and running on the machine before starting the process, but Andries gives you everything from there - installing the needed Sun JDK, Xdebug, adding the packages for PHP_CodeSniffer, PHPUnit and phpUnderControl and the scripts to get phpUC and CruiseControl to work together. He also includes a sample project so you can see how to fit yours in.

He's laid out a map of the tools that can all interact to create a more robust environment for automatically building and testing your code. Here's his list:

• PHP_CodeSniffer
• phpmd
• phpcpd
• PHP_Depend
• PHPUnit

The results of all of these tools running on your code is then fed into the CruiseControl instance and passed off to phpUnderControl for final deployment.

In any decent sized project, the more times you commit code, the bigger the chance is that you will break something. [...] To deal with this we can either adopt the '�release and pay'� method of software control, or we can setup systems to help us find the consequences of our actions, so we that can correct them before they become a problem. We usually call these systems Continuous Integration systems.

He briefly covers what phpUnderControl is and what it can do for you before getting into the real detail - grabbing all the needed packages (including the eZ components graphing library), setting the system up and configuring it for a sample project. This includes setting up the XML configuration file and adding in PhpDocumentor/PHPUnit/PhpCodeSniffer. He adds in two "nice things to have" at the end - emailing when something breaks and setting up/tearing down a database as needed.

there were some things that I had to discover via trial-and-error with regard to the build files, though possibly they are covered in other pUC docs that I didn't check. The "Getting Started" build example is based on a project sandbox pulling code from a Subversion repository, whereas all my PEAR code comes from CVS.

He talks about his config.xml file (how it turned out that the basic one was all he really needed) and configuring the build.xml to run the tests from the correct location. He also mentions some future ideas like making the builds run the install/upgrade commands before running the tests.

From the first moment I was introduced to the concept of continuous integration I have been really interested in this. I've been playing with several packages for CI and set them up for fun. One thing that kept bothering me was that I could not test my own symfony projects with it. I started working on the symfonyUnderControlPlugin a few months ago, and quickly had a working proof of concept. It wasn't perfect, but it did the job.

Strapped for time, he didn't get much chance to work on it until the company he works for (Ibuildings) gave them time to work on Open Source projects. The results is his preview release, version 0.0.1.

I was entasked recently with getting a continuous integration environment set up. phpUnderControl seems to be the tool of choice for this these days, so I started off in that direction. [...] Obviously I needed to install PHP itself. CruiseControl is a daemon written in Java, so that needed to be installed as well. Our Linux distro of choice is Debian. With these requirements, I set out.

He walks through the process - downloading the Debian ISO and installing in a VM, installing the needed packages, setting up the correct environment and getting everything started up and running. The end result is a local CruiseControl server with PHP integration, a web interface and plenty of configuration options you can customize for your needs.

The @failonerror-attribute of the -tag in the merge target was set to false, which results in not failed CruiseControl builds. To fix this behaviour, you must modify the merge target in your build.xml.

He includes an example of the fix, showing where to change the failonerror attribute of the exec tag inside of the target. This is also corrected in the most current build, so update your software to prevent issue.

I currently released a new version of phpUnderControl. Beside some minor fixes this release comes with a new feature to aggregate test results of multiple PHPUnit runs. Use the new cli command merge-phpunit of phpUnderControl to merge multiple log files produced with PHPUnit, as shown in [this] example build file for ant.

He defines the XML file to set up the merge for the different PHP binary versions and the merge script to use. A screenshot of the result as presented inside the tool is included.