Continuous PEAR

As part of developing web applications most of us will probably also be creating some (hopefully) useful, reusable libraries. And in the PHP world, the standard packaging and distribution format is PEAR.

PEAR has been around for over 10 years, and is now being progressed with PEAR2 and Pyrus. Whilst it is used by a bunch of high profile projects (including PHPUnit, Symfony, Phing, and Digg), it doesn’t seem to have received the kind of ubiquitous support that Gems do in the Ruby world. This is a shame, as managed libraries provide a bunch of advantages over manually trying to control dependencies with techniques like SCM tools (SVN externals, or Git submodules), or just plain old checking out code and possibly versioning it alongside your application. Managed, packaged, libraries provide a consistent approach to both installation and receiving updates. They allow specifying and resolving dependencies on other libraries. And they ensure a more componentised, orthogonal approach to developing reusable functionality. Phew, that was a lot of serious words...

At Box UK we’ve recently started to package libraries in our PEAR channel. We’ve also coupled this with our CI process to try and make the creation of packages, and the maintenance of our distribution channel as simple, painless and automatic as possible.

So here’s the setup...

• Developer adds new features
• Testing and QA is performed
• A new tag is created for library
• CI picks up tag, new package is built and deployed to PEAR channel

The last step is key. After tagging it should all be performed automatically; the developer shouldn’t have to worry about how the library is packaged and distributed. Instead, they just wait a few minutes for everything to kick off, and then their code is available to be pulled down wherever it’s needed.

Console output from our PEAR package build

This means that firstly there’s less to do, but more importantly once set up there’s less to get wrong or forget, and also frees up the possibility of distributing via multiple methods without the developer ever having to change their workflow.

Below is a diagram showing the main components of the system and the process from tagging through to pushing to the PEAR channel.

Diagram of build process components

We use Pirum to manage our PEAR channel. And as Stuart Herbert suggests in his blog series about maintaining a PEAR channel, we keep the entire thing in an SCM repository. To update the channel is then a matter of committing the new package to it, and updating the checkout on the web server that hosts it. This gives us assurance we can roll back when things go wrong without completely duffing up our whole setup.

This is a reasonably new system that we’ve put in place at Box UK, but it’s working well so far. Having our code available in a managed format is aces, and makes distribution, installation and upgrades a breeze. We’re finding more and more that isolating our components increases their quality and re-usability, so anything we can do to make this process simpler is a Good Thing.

http://pear.php.net

http://jenkins-ci.org

http://github.com/boxuk

http://pear.boxuk.net