Before I get into this one I would like to note that while I have presented several options (and will presenting one more after this) that none of these are given with the assumption that they are the only way or even the best way to do things. Each of these options is provided as a starting point. What that means is that you need to try it yourself and modify what I present here to fit what you need.

With that; PEAR. PEAR stands for PHP Extension and Application Repository. What it does is allow you to maintain very PHP-friendly packages in a manner that is native for PHP developers. What that means is that you are able to package up your application in a way that is easy for you to understand. But in order to deploy your application we need to discuss a few concepts.

Concepts

First PEAR2. There is a PEAR 2. It looks a little light right now in terms of packages, documentation and links that work on the site. So for that reason I will stick with PEAR 1 as an example.

Next, channels. In order to make your application available to your production servers you need a channel. A channel is just an HTTP server that has some data in pre-defined areas so the PEAR binary knows where to look for it. There are several options that you can have to setting up a PEAR channel. Chiara and Pirum are the two that I have most heard about. I chose Pirum because it is really easy to get up and running.

The first thing we will do is get our channel up and running. To do that we need to follow the instructions on the Pirum page, which I won't bother going over (since they're already there). But I will show how to set up the channel.

Creating the Channel

First create the directory on your deployment server where you want the repository to be located. Then you need to place a file called pirum.xml in that directory, which has a simple XML format that is used to initialize the channel.

But a repository is useless without something to repos… er.. distribute. For that what we will do is simply export our Subversion repository to a directory somewhere where we can start building our package.

Building the Package

The next thing we need to do is build the package. But how does one do that with PEAR? With a package.xml file. That's how. The problem is that a package.xml file can actually be a little lengthy. Another problem is that it needs to have very exact details about each and every file that you want to deply. The way I worked around that is to create a base package.xml file that I use as a template and then use a simple script to find all the files and add them in there. First the package.xml.

What this script does is state which directories to search, loads up the package.xml file into a simpleXML object and iterates over every file and adds it to the content node. If we run this code we get the following output.

Deploying to the Repository

If we look at our package.xml file now we will now see a list of all of our files. Now what we need to do is have pear package it. How do we do that? With "pear package". However, before we actually build the package we need to tell pear that our repository exists. "pear package" will refuse to create a package for a repository that it does not know about. So we need to tell PEAR about our repository. We do that by issuing the following command.

What? What's this "xen2/pear" thing? Think of it like http://xen2/pear. Or, with a fully qualified domain name xen2.eschrade.com/pear. It's basically the URL that is used to locate the repository. Now that we have our channel discovered we can package our package.

Installation

We now have our PEAR channel set up to deploy our application. Now all that's left is to set up production server.

The first thing to do is discover the channel, just like we did before. However, we need to do something before we actually do the deployment. If you look back at our build-pear.php code there was a line where I stated the role of the files. While you can have multiple roles I defined all of mine as being www. That's important because PEAR likes to deploy files to the PEAR root, which is probably not where you want them to go. To define that, change the following setting for PEAR.

Conclusion

PEAR is a pretty good option for you to deploy your PHP applications with. It takes a fair amount of work up front (perhaps PEAR2 will make this easier) but all of that is scriptable. And since it's written in PHP you, as a developer, you have a lot of control. The problem is that you, as a developer, should not have access to the production environment. That is almost always the domain of system administrators. Why? You might be tempted to fix something. But PEAR is really good when you need cross-platform deployment and a lot of developer control over the deployment.