Continuous PEAR

As part of developing web applications you may come into contact with the PEAR distribution format. Rhodri Pugh explores the benefits of Continuous PE
Rhodri Pugh

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.

Managed libraries

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…

Automation from tags

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.

Continuous PEAR

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.

About the components

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
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.

Wrapping it up

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.

Related links


Add a comment

  • 17 Aug 2011 16:17

    Jenkins is a bit overkill for a few scenarios. I’ve developed Cintient, a PHP CI server that right now will report on several metrics for your source code. I’m working on the deployment part, though… If you find some use for it, it’d be cool. Cheers.

  • 20 Aug 2011 23:58

    Cintient looks interesting… Jenkins gives you a whole bunch of stuff though and is well supported, I don’t know about it being overkill for anything, provided you can dedicate a server to it.

    I’ll try to take a look at Cintient over the next couple of weeks

Add your comment

If provided, we will link to this from your name