Comments on: Setting up continuous integration for PHP using Hudson and Phing

By: Ben Waine

Ben Waine — Fri, 30 Jul 2010 13:29:11 +0000

Hi Dave,

I followed your advice regards the build being rsync’d to an ‘alpha’ staging area.

Works a treat, though it was a little fiddly setting up the public / private SSH keys!

Thanks,

Ben

By: Dave

Dave — Mon, 19 Jul 2010 12:12:00 +0000

It depends on how you want the deployment to work; what you’re requirements are. Previously, I have tweaked the “build” script to create a “deploytoalpha” Phing target. This was pretty simple stuff, using rsync to get the data over.

Right now, I’m working somewhere where things are more sophisticated and actually less “automatic”. A developer must submit a ticket to deploy staging release, and this must involve a tagged version of the code (in SCM). This system doesn’t integrate (currently) with our Hudson setup.

By: Ben Waine

Ben Waine — Mon, 12 Jul 2010 16:22:50 +0000

Dave,

I found this guide really useful, thanks very much for taking the time to blog it!

Have you got any insight into automatic deployment to staging and also did you learn anything about getting phpdpend graph on the main dash?

Ben

By: Dave

Dave — Fri, 18 Jun 2010 16:13:37 +0000

The build script in my example is fairly light-weight. You’re right – the “app” target is pointless. However it really depends on what you want your build process to “do”. New build scripts that I’ve got do things like crunch config scripts to generate code and look at code annotations to work out dependency injection container “wiring” config. These all lie in the “app” target. Further more I’ve added in some other targets to do things like deploy to a staging environment… there’s loads you can do here.

I guess that “build” as a concept is more obviously useful in the context of compiled apps where you actually have to build them! Things like PHPDoc and/or CodeSniffr etc.. can really just run on the raw “source” code (as checked out of SCM).

That said it all depends what you do! I’d urge you to have a play with a build.xml file. Automating things is a very powerful thing and I find it very useful. That said, if you wanted you could probably not use Phing and just use Hudson to do the heavy lifting.

By: ff78

ff78 — Fri, 18 Jun 2010 15:20:20 +0000

Hi,
I don’t understand how it can be used especially the build.xml

What’s the role of the “app” target ? The app folder is empty so there’s no php files for phpdoc…

Regards.

By: Dave

Dave — Thu, 03 Jun 2010 08:26:07 +0000

@EllisGL
Yep – you’re right about the build command. This amended version will make sure every Phing “target” gets executed. Another interesting point here is that you can setup different Hudson jobs to execute different targets. This is handy if the “full” build takes too long – in this situation you can setup a build that only executes a subset of tests (for example).

By: EllisGL

EllisGL — Wed, 02 Jun 2010 17:21:49 +0000

The build command should be:
phing -f $WORKSPACE/source/build.xml prepare app phpdoc phpcpd pdepend phpcs phpunit -Dws=$WORKSPACE

By: Dave

Dave — Mon, 17 May 2010 12:46:59 +0000

@drahreg80 – Yes you’re right about reporting on PHPDepend.

Not sure about the graph. Let me know if you find a way of getting this displayed.

By: drahreg80

drahreg80 — Mon, 17 May 2010 11:58:42 +0000

Did you forgot to choose “Report JDepend” under Post-build Actions? Value should be like “build/logs/jdepend.xml”.

Is there an way to show the graph of phpdepend in hudson?

By: Dave

Dave — Mon, 17 May 2010 08:04:48 +0000

If your application uses the Zend Framework (I assume that’s what you mean) then that’s fine – nothing in this post needs to be changed. You just need to make sure your unit tests have included the ZF bootstrap/autoloader. Hudson doesn’t care what kind of PHP framework / technologies you use.