• It will not handle deployment. This particular web application is deployed by the client’s IT department.
• It will create a ZIP file (it could just as easily create a tar.gz file) that the client’s IT department can extract and deploy.
• It will rename the document root since the document root is a different directory name in the client’s production environment then it is in our development and testing environments.

Next, an outline of what the build does:

1. Prompt for Subversion credentials (I’d rather not store these in a file).
2. Prompt for the Subversion tag to build from.
3. Delete the source directory if it exists.
4. Export the given tag to the source directory.
5. Rename the document root.
6. Create a ZIP file, named after the version, of the source directory’s contents.
7. Clean up after itself by deleting the source directory.

Both of the build files are in the project’s root directory (in my project, this is one directory above the document root). The build.properties file defines three properties: document root (so we can rename it to this new name), the source directory (the place to export to and then manipulate folders/files), and the URL to the repository’s tags directory.

The build.xml file is the actual build script, performing the actions outlined above. I’ve obfuscated the project name to be “acme”. I could not find a way to create a prompt that hides the Subversion password as it is entered (anyone?). For renaming the document root, I used the exec task to execute a move (mv) command since the move task failed for me (so this script will not work as-is on Windows).

Executing this script is as easy as running phing build-tag (once Phing is installed) from within the project’s root directory. Please let me know if you have any questions or see any room for improvement.