Article
0 comment

Why you should not deploy web applications with unix packaging tools

Packaging and deploying web applications, e.g. PHP apps, can be a very tough topic. One way to deal with automatic deployment and dependencies is to use the packaging tools your unix server supplies, e.g. debian *.deb packages. This approach has indisputable benefits:

  • it manages dependencies
  • it’s possible to manage the deployment process on several servers automatically
  • there is a complete existing infrastructure for this task

But (you knew that would come, didn’t you?): packaging systems like the one used on debian are targeted to control that the package is installed in exactly one version (certainly not always, we’ll come to that later on) in one defined place. Igf we use multiple versions of the same software, it’s version number will define where they will be installed. You get a version tree like:

/usr/local/lib/…
…/applib-1.1/
…/applib-1.2/
etc.

Most system packaging tools also allow you to specify a prefix where to install the package. But altogether its a special tool for a special task.
Using it for web application deployment looks like the “if all you know is a hammer, every task looks like a nail” paradigm. You can accomplish the tasks needed but you have to modify the standard processes very much.
For example I would like to be able to install exactly the same software twice on exactly the same machine. And yes I absolutely definitely want to have two times the same version of the code in different locations. Here the notion of the packaging systems paradigm of a “system” as a whole server and not a virtual host or any other subdivision of a system is in the way.
I prefer to use build systems like phing, ant or make to wrap up things. Especially phing in combination with DbDeploy is a very comfortable way to do things you don’t want to handle manually in the PHP universe.