Continious integration; how it all fits together

Written by Wilco Jansen Friday, 02 October 2009 10:00

Quality Assurance Puzzle with Cruiscontrol and surrounding PHP tools

The term 'Continuous Integration' originated with the Extreme Programming development process, as one of its original twelve practices. When I started developing in open source we worked together with a group of open source (volunteer) developers, having some basic infrastructure like version control and coding guidelines in place. But every individual developer was responsible for the quality of the whole, resulting in various areas of the code-base to break after almost every commit. Within Joomla this problems still exists even with the Joomla Bug Squad acting as the main quality gate, but realize this is only for the current stable release and does not apply to the 1.6 code-base.

An important part of any software development process is getting reliable builds of the software. Despite it's importance, we are often surprised when this isn't done. Within the Joomla project the quality of the CMS is maintained manually by a group of people, and I found out that this is a very time consuming in an environment where a simple fix in the software can break a lot of other areas. The continuous build blogs have shown which (open source) tools are available to implement a continuous build environment. In this article I will explain how the various tools can be combined together to implement a continues integration process. It stresses a fully automated and reproducible build, including testing, code analyses, API documentation and (if needed) package generation process that runs after every commit. One of the hardest things to express about continuous integration is that makes a fundamental shift to the whole development pattern, one that isn't easy to see if you've never worked in an environment that practices it. In fact most people do see this atmosphere if they are working solo - because then they only integrate withthemselves. For many people team development just comes with certain problems that are part of the territory. Continuous integration reduces these problems, in exchange for a certain amount of discipline.

The fundamental benefit of continuous integration is that it removes sessions where people spend time hunting bugs where one person's work has stepped on someone else's work without either person realizing what happened. These bugs are hard to find because the problem isn't in one person's area, it is in the interaction between two pieces of work. This problem is exacerbated by time. Often integration bugs can be inserted weeks or months before they first manifest themselves. As a result they take a lot of finding.

Let us examine how the various tools can be put together.

Below the ingredients for setting up a continuous build environment based upon CruiseControl and phpUnderControl are listed. Some of the tools have been described in previous articles on JFoobar, some will be new when you read them. We might spend some time on additional blog posts in the future on JFoobar, in the mean while we suggest you read up on the information available on the Internet.

Version control - A versioning system is required, Joomla uses Subversion. Joomla offers anonymous access, the top level location for all that is stored in Subversion can be found at http://joomlacode.org/svn/joomla/development/
phpunit - Used for implementing unit tests.
phpcs - PHP codesniffer, see also the article describing how to validate coding standards.
phpmd - Scans PHP source code and looks for potential problems such as possible bugs, suboptimal code or overcomplicated expressions.
phpdepend - is a PHP software metrics tool.
phpcpd - This is a Copy/Paste Detector (CPD) for PHP code, see also the article describing duplicate code detection.

The image below gives a graphical overview on how these tools all come together.

Image of various PHP tools integrating into cruisecontrol

The PHP tools generate standard XML output that can be interpreted by CruiseControl. This is a tool developed on the Java platform as continuous integration platform. phpUnderControl is an addon to CruiseControl, which integrates some of the best PHP development tools. This project aims to make your first steps with CruiseControl and PHP as easy as possible. Therefore phpUnderControl comes with a command line tool that performs all modifications to an existing CruiseControl installation.

A build is triggered by a commit done by a developer. The trigger can be initiated by the version control system or by polling the versioning server if something has changed. A typical build runs very fast but when you start using phpUnderControl keep in mind the API documentation also is automatically generated using phpDocumentor which can take considerable time if you have a big code-base to manage. Most of the times the code-base is split into specific areas to overcome long build times, within Joomla you would for example separate the framework from everything else.

You need a separate (virtual) machine to install the software. It is pretty straight forward to get Cruisecontrol and phpUnderControl up and running. Please read the installation description for phpUnderControl. The builds are run by an build script, Ant is used to perform the required tasks during a build cycle. The syntax and usage is pretty straight forward, check the getting started and command line section in the documentation section of phpUnderControl to get a basic system up and running.

About the author Wilco Jansen

Wilco was born in 1967 in the Netherlands where he still lives. After years of being a programmer Wilco has worked as project manager and IT manager. Discovered Joomla! when he was creating his own content management system, and never lost focus after then. Joined core team as development coordinator in May 2006 just helping to make Joomla! even better then it is already. Wilco has been deeply involved in the Joomla project as Google summer of code program manager 2006, 2007 and 2008 editions, co-organizer of the Google Highly Participation contest in 2008, first ever development coordinator, creator of the Joomla bug squad, member of the board of Open source matters, regular speaker on world wide conference advocating Joomla and much, much more. Wilco has a bachelor degree in business and information engineering and studied Master of Science knowledge and information engineering at the Middlesex University in London.

More about Wilco Jansen

There are 7 comments posted.

# 1 - Posted by: Marius van Rijnsoever on 2009-10-04 13:14:08

Thanks for the awesome article Wilco!

We have just installed cruisecontrol for JFusion after reading your article and it will make life much easier automating releases (although we already had batch scripts setup to create new releases), such as automatically updating our API.

The coding standards are very interested. Even the PHP website itself lists statements incorrectly.

require_once($filename)

should be:

require_once $filename

according to the PEAR/Zend "standards". If everybody including PHP itself (and joomla) does it wrong, you got to question the usefulness of some of the "errors" that phpcs generates.

Great overview and trying out some of the addons like phpmd and phpcpd now. Cheers, Marius

# 2 - Posted by: Wilco Jansen on 2009-10-04 13:21:20

Hi Marius,

Tomorrow I will publish a post about presentation I gave today at the TDose event, might be of interest also.

The coding standards, but also the copy/paste detection really are an eye opener, even when you think you did everything right, thise tools will help you find the smallest errors. As I pointed out in a previous article, Joomla has a long way to go if they want to improve the basic level of the codebase, would be interesting if I could work on that specific job for the project ;-)

Thanks for your reply anyway!

# 3 - Posted by: Marius van Rijnsoever on 2009-10-05 12:41:40

It is definitely an eye-opener to use the cruisecontrol software. I had never heard of this software before and just love it after starting to use it. Maximising code standards is very important and is much easier to do with the detection tools you described. On our codebase simple formatting issues (indentations) showed up in the report even though we regulary use php code beautifiers. I installed the package php beautifier to clean up any code automatically:

sudo pear config-set preferred_state beta

pear install PHP_Beautifier

then follow the following doc to clean up the code from the command line:

http://beautifyphp.sourceforge.net/docs/PHP_Beautifier/tutorial_PHP_Beautifier.howtouse.commandline.pkg.html

Now we only have some issues with doc tag order, line breaks between class definitions, require_once and too many characters on a line to tackle.

Interestingly the ZEND model is much different from the PEAR coding standard. With it even analysing your variable names. $Itemid and $item_id do not follow the standard and it must be $itemId or $itemid. Obviously changing such a basic parameter name would cause many conflicts with 3rd partly libraries.

Also coding standards apparently require "Class name must begin with a capital letter" (PEAR), which would cause issues with the current plugin system of Joomla that requires it to start with "plgUserxxxxxxx".

Since Joomla has such a large established userbase, with lots of 3rd party app developers, it will be hard to make the code 100% compliant. But it is very important to do as much as possible. We are currently redeveloping our jfusion framework and will be aiming to make it as close to 100% compliant as possible (as we can do this as we develop almost all jfusion plugins ourselves and can therefore dictate standards/api).

Thanks for a very interesting article. Marius

# 4 - Posted by: Wilco Jansen on 2009-10-05 15:33:48

Hi Marius,

You example show exactly what the importance is of strictly following the coding guideliness. One moment people use "$ItemID" the other moment they use "$itemid". It depends on the situation, but dependency to this in regard to 3rd party developers is an issue.

I would suggest an effort in the Joomla project to make 1.6 at least compliant on the coding guideliness level. This argument is valid in my opinnion since 1.6 is a major change (although it marked as minor release), and not many extensions will work with 1.6 out of the box, this is a perfect moment to set things right.

In the Joomla codebase 80% is indeed comming from identing errors, the rest is due to real violations of coding standards (and a small percentage is about breaking line length standard).

As said before, the work can be done and I would be willing to work on that for the project (of course assembling a group of people who are willing to help out). Getting into compliance with coding standards is the first stage I envision, the next stage would be writing the unit tests for the framework level code (and start with Sellenium for UI testing)...

Re: Nice blog entry!

# 5 - Posted by: Jeffrey Fredrick on 2009-10-14 06:29:40

Cool entry. I really like your puzzle piece diagram.

And glad to hear you're like CruiseControl.

If you want to have more exposure to the wider world of CI you might checkout CITCON, the Continuous Integration and Testing Conference.

Jtf

# 6 - Posted by: Marius van Rijnsoever on 2009-12-08 04:05:28

Hi Wilco,

Just reporting back on the CI progress on JFusion. The JFusion framework is now almost 100% PEAR compliant with only 38 code warnings in 12000 lines of code. It was a very big job, but now it is very easy to check the code for integrity before a release.

http://www.jfusion.org/index.php/info/blog/JFusion-1.2.1-released-new-API-and-PEAR-compliance.html

The main issue holding back compliance now is the fact that class names for views do not begin with a captial:

http://www.jfusion.org/media/sniffer_1.2.x_details.htm

However changing this would mean all 1.5 components would have to be changed, unless some sort of legacy code could be introduced.

How are things going with CI on the joomla front?

Thanks, Marius

# 7 - Posted by: Wilco Jansen on 2009-12-10 22:34:25

Hi Marius,

Awesome to see you have CI implemented! If you also get unit testing in place, you will see that you find issues before you deploy, and quality will go up very good.

Paladin is doing a really good job writing the unit tests, but coding standards still are not set in a final stage, and CI is far away for Joomla...that is where it is atm.

Regards, Wilco

Help for creating beautiful comments.