Deploying cron jobs using Phing

Deploying applications that depend on cron-jobs can be a pain. However, Phing can be used to make such deployments easy - here’s how…

Consider an application folder structure as follows:


All development work takes place within the /src folder while the /builds/* folders are used as targets in deployment. This system allows multiple builds to happily co-exist on the same server and the whole application infrastructure to be moved between servers easily as the structure in source control mirrors that of the server.

In this example e-commerce app, we have a number of scripts (in /src/scripts) that handle order-processing which need to be called periodically by the cron daemon. A naive approach in deployment would be to export the codebase to an appropriate build folder but then edit the server’s crontab by hand and add the appropriate lines to run these scripts.

This isn’t such a great idea though as it relies on that most unreliable facility, human memory, to ensure the build is fully deployed - this creates an unnecessary overhead which is bound to lead to mistakes. Furthermore, the overhead acts as a deterrent for using asynchronous jobs within an application, limiting the app in terms of what it can do. As far as I am aware, there is no easy way to automatically update a user’s crontab automatically.

A much better way is to create a number of scripts which specify the cron tasks and are deployed to the /etc/cron.d folder. In the above example, these are stored in /src/cron.d and would look something like:

15 * * * *   root   /var/www/ > /dev/null 2>> /var/log/cron.errors.log
35 * * * *   root   /var/www/ > /dev/null 2>> /var/log/cron.errors.log

(Note that, for some reason, a blank line is required at the end of this file in order for the script to be run by cron.) Here, the __BUILD__ is a tokenised parameter which will be replaced during deployment to configure the path to the appropriate script - a phing trick I’ve described previously.

One further complication is that if both the dev, test and stage builds are running on the same server, then the scripts deployed to /etc/cron.d could clobber each other as they have the same name within each build. This can be neatly side-stepped using the Phing’s glob mapper to replace the __BUILD__ component of the file to be the appropriate build name (similar to how the paths are configured within the file itself).

This is probably best illustrated with a sample phing script which takes the build name (eg “development”) as a parameter:

<xml version="1.0" encoding="UTF-8"?>
    <target name="deploy">
            <fileset dir="/etc/cron.d/">
                <include name="appname-${}-*" />
        <copy todir="/etc/cron.d/">
                <replacetokens begintoken="__" endtoken="__">
                    <token key="BUILD" value="${}" />
            <mapper type="glob" from="appname-__BUILD__-*" to="appname-${}-*" />
            <fileset dir="${}/cron.d">
                <include name="appname-__BUILD__-*" />

The illustrated snippet does two things:

Deletes any previous scripts for this build from /etc/cron.d (this is why we namespace the files with “appname” to prevent accidentally removing a system file). Copies the new scripts into /etc/cron.d while replacing the token __BUILD__ with the build name in both the file contents and file names. After separate deployments for dev and stage, we should find the following:


where, for instance, the contents of /etc/cron.d/appname-development-order-processing would be:

* * * * *   root   /var/www/
* * * * *   root   /var/www/

Having automatic and reliable deployment of cron-jobs in place is quite liberating. Suddenly, lots of application processing can be done asynchronously without worrying about the overhead of maintaining the appropriate crontabs by hand.


Something wrong? Suggest an improvement or add a comment (see article history)
Tagged with: phing, deployment
Filed in: tips

Previous: Auto-generating an FAQ with Prototype
Next: A pseudo-code job advert and its discontents

Copyright © 2005-2023 David Winterbottom
Content licensed under CC BY-NC-SA 4.0.