2 minute read

In my development work for Clockwork Robot, I have always used the ANT build tool for packaging and deploying client sites. I chose ANT for its platform independence and its XML syntax, which cleanly decoupled build and deployment from the language that the websites were built in, usually PHP.

While ANT was developed for Java development, it works equally well for the deployment of applications written in any language. I reasoned that the limitations of ANT scripts would provide useful constraints for any developer/release manager trying to bend the build and deployment process to do inappropriate things.

Furthermore, at the time that I adopted ANT, it was far superior to the current alternatives, which were usually cryptic and brittle GNU Make files or, worse yet, Perl scripts that guaranteed employment for an incorrigible and obstreperous sysadmin. Plus, XML promised to be a lingua franca, a sort of utopian language that would solve all our problems and serve umbrella cocktails poolside.

New Tools

Well, Esperanto was supposed to be a problem solving universal language, but it is only dear to tenacious eccentrics who find its constraints useful, and harbour delusions of semantic elegance. Which, as it has recently and painfully been pointed out to me, is how I have been behaving about ANT.

The problem is that while ANT is independent of the language du jour of your current web app, that usually means that the skillset to develop and maintain the build and deployment scripts, is also independent of the experience or ambition of your developers.

Increasingly, Clockwork Robot clients are using PHP applications written in popular frameworks like Symfony, or CMS like Drupal or Joomla. These frameworks may provide their own deployment tools, otherwise PHP projects like Phing provide ANT-like alternatives.

Meanwhile, for server administration and heavy lifting on the command line, Python has become the language of choice. Since it reads like executable pseudo-code, PHP developers are generally comfortable with picking up Python skills, and since Google and NASA use Python, it must be cool.

Move over ANT

Enter Fabric, a build and deployment tool written in Python. While the syntax is just bog-standard Python, it carries a lightweight API that gives just enough useful functionality without getting in the way. The syntax is less verbose than ANT, given there’s no need to open and close tags, and execution of the commands on the command line are just as easy in Fabric.

Since Python has become a commodity skill for developers and sysadmins alike, I’m now considering a move from ANT to Fabric. It makes more sense for project resourcing, that the scripts can be built and maintained by whomever is closest to the deployment coalface at the time; developers or sysadmins.

In upcoming posts, I’ll be demonstrating the installation and use of Fabric, and running a closer comparison of the two tools.

ANT Fabric
Advantages
  • Excellent documentation
  • Wide availability of extension tasks and libraries
  • Widespread integration with popular continuous integration and deployment tools such as Hudson </ul> </td>
  • Simple Python syntax
  • Superior SSH integration built in </ul> </td> </tr>
Disadvantages
  • Complicated or custom tasks require Java coding
  • Verbose syntax
  • Java implementation makes it inaccessible and unwieldy for systems administrators </ul> </td>
  • Relatively new project
  • Scant documentation </ul> </td> </tr> </tbody> </table>