Phing

Providing a Phing build file along with a project is a good way of allowing automation of certain aspects of the project. The only trouble is that users won't know what's in the build file unless they open it or just run it. You could provide documentation along with the build file so that users know what to use the file for, but a better approach is to list out the targets available in a project. This can be done easily by using the -l (lower case L) or list flag, which will just list the available targets in the supplied build file.

Running this on a build file will produce this sort of output from a build file with two targets, one of which is run as a default.

The other day I was experimenting with Git hooks. These are scripts that you can execute before certain actions are run in Git. For example, you might want to ensure that forced updates are not run, ensuring respository files have the correct permissions after merging, or that the files have ASCII standard names before being committed.

To use a hook in Git you just need to add them to the .git/hooks directory in your respository and to change the mode of the file so that it is executable. A new Git repository will create several sample hook files that can be used by removing the '.sample' from the end and making them executable. For more information on Git hooks and how to use them see the Git hooks manual page in the Git documentation.

I use Phing for a lot of different tasks, it helps me to automate things that I would otherwise mess up if left to my own devices. Prime candidates for Phing scripts are things that I don't do that much and forget how to do them, or that have a number of complex steps. The only problem I have found is that because many of the Phing scripts I create rely on system changes (eg, configuring an Apache server) they therefore require system changing privileges. Normally I would just prefix the Phing command with sudo, but every now and then I forget all about that step and the build fails. This can be dangerous as I am then left with a build that failed, which might leave a system partly configured or even take a server offline.

Phing is an awesome tool for automating things and I use it more and more for automating all kinds of different tasks. One of the tasks that I don't tend to do all that much is setting up a new local virtual host for Apache on my development machines. I know how to do it, but there is always something I forget to do, or a convention that I don't follow which means that I have to repeat myself at a later date to fix something I have missed.

So to make my life a little easier I decided to create a Phing build file to automatically create a virtual host and the everything associated with it in one go. Essentially, I would need to do the following tasks:

To make things a bit quicker when using Phing on Windows use the following registry entry to create a right click option that integrates with Phing.

Phing allows the running of SSH commands on servers and the copying of files to servers via SCP. Before you can use SSH and SCP commands in Phing you need to install the PECL extension SSH2. The SSH2 PECL extension requires the libssh2 package, so you need to install that before you can get started. The following install instructions are based on a Linux environment.

Download the libssh2 package from www.libssh2.org and install it by using the following commands. Your package version may vary.

Automatic building with Phing makes deploying to a server nice and easy, and if you are using SVN as your source control system then you can easily deploy directly from your repository to your web server.

To allow Phing to utilise an SVN server you must first install the VersionControl_SVN pear library. Although this is in alpha release I have used it quite a bit with no issues. The only thing is that you will need to specify the version number to pear if you want to install it, like this:

pear install VersionControl_SVN-0.3.4

To get Phing to export from an SVN repository you can use the svnexport task. The following build file sets up some parameters (for use in this task), runs a target to delete the existing export and then runs a target that exports from the SVN repository we have set up.

Although most developers might not like it FTP is quite a common way of deploying the files for a site to the server. To simplify this process Phing comes with a handy FTP transfer action called ftpdeploy.

In order to use the ftpdeploy we first need to install the Net_FTP package. To install this package just enter the following command:

The first thing we need to create is a build.properties file to store our ftp details

The other day I needed to copy a Drupal project from my source folder to another folder, so rather than manually copy the files I decided to create a Phing script that would do it for me in one go. This Phing script will export your Drupal project into another directory, change the database credentials and create zip and tar files of the project. The first thing to do is create a properties, here is the contents of that file.

When you run a phing script it will print things out to the console. These messages are either system messages (eg. BUILD STARTED) or echo messages that you have put into your build.xml file. All of this output is controlled and created by a logger file. The default logger is called (unsurprisingly) DefaultLogger and will be used as a default. There are a few different types of logger available, all of which can be found in the listener folder in your PEAR\phing directory.

To select a different logger script to be used just use the -logger flag in your phing call. To specify the DefaultLogger use the following:

To specify an XML logger that will create an XML document of the phing events that occurred in the current working directory use the XmlLogger logger.