A Phing Tipping Point

One of the most benefical tools I picked up this year is Phing, a build system for PHP based on Ant. I had known about it for a while, but never made much headway because I didn't think I needed to do any building. I already had rsync scripts--I figured I was set. It's just PHP.

WordPress deployment was my Phing tipping point. The first time you deploy a WordPress site from development to staging and realize that the paths inside your database dump are all wrong for is the first clue you need Phing. The next clue happens when you need to pull from production back to development, and face the same problem in reverse.

I had previously been using Bash scripts for this sort of thing. I had one for pushing out from dev, and another for pulling in. Bash scripts are great. The problem is keeping track of them. A few months later I needed to do some maintenance work, but the magical combination of which scripts needed to be run in which order was no longer apparent. Plus, I had done another WordPress project in the meantime and set things up slightly differently. The changes hadn't been propagated back to the first project. Things ended up semi-automatic and half-effective.

Phing clicked for me once I figured out ExecTask was the gateway to rsync. Rsync is crucial for getting files from point A to point B in a sensible fashion, so I always gave up when I couldn't find any mention of it in Phing's manual. Eventually I did find reference to a third-party RsyncTask, but I stuck with ExecTask because it's built into Phing and applicable to just about any shell command you might want to run.

Once you can run shell commands, pretty anything is up for grabs. Phing started to make a lot more sense because it was a standard tool that could wrap the eccentricities of an individual project with consistent behavior. I no longer needed extra bash scripts in my source tree, just a single build.xml at the project root.

Phing is great because it covers the basics but keeps PHP at close hand if you need it. There's not much of a learning curve once you get the hang of declaring and using variables (properties) within the context of XML. If you keep things abstract enough, build targets are pretty easy to reuse between projects. Once you figure out how to flip your WordPress database between environments, the only things that need changing from project to project are hostnames and filesystem paths.

For example, in an earlier post on revving file names, I described a way of using Phing to add hashes to filenames for better cacheing. Dropping that into another project doesn't cause much toolchain disruption because you have one thing orchestrating everything from start to finish, instead of independent scripts each doing their own thing.

That's the part that I was missing. I was managing the build and deployment process every time I needed to make an upate, instead of defining the process once and reaping the benefits of true automation.