Deploying PHP Applications?

So, a question for everyone out there – we’re looking to do a bit of an overhaul for our build and release system and I was wondering what kind of setups you all out there had for your releases?

I’ve seen all sorts of different things (including a version control->rsync to production push and a fully CruiseControled push for everything) but I wanted to hear back from you fellow PHPers out there as to the kind of stuff you’re using. We’re looking to try to keep it open sourceish stuff, so suggestions down that line would be best but we’re pretty open.

I don’t have much experience with a more formalized build process but we’re coming up against a need to separate out the responsibilities a bit more.

What do you use for your build (and deployment) process for your PHP applications and websites?



  1. I use Phing. It’s written in PHP and since I was already familiar with Java’s “ant” I was quite comfortable with it. I highly recommend it.


  2. Bazaar, which does all our version control and can either checkout (watch the .bzr dir!) or export (optionally to an archive). Once an archive is complete you can build a deb or rpm for the app and install the app using the system package manager.


  3. I use rsync, actually symfony rsync command line, that lt you configure and update multiple environments (dev, staging, qa, live and whatever you call your environments). Works pretty well.
    The only problem we have is the synchronise the DB structure and configuration datas that are in the DB.


  4. is what we run for all builds, PHP, Java, Perl. We even have started to use it to admin the servers with their latest CTL tool.

    Once you get it understood you can do a lot, we deploy apps across a couple hundred machines with some configs with automated rollback etc. and we have simple installs that just take care of two machines.


  5. We use a few different apps (phpUndercontrol, Phing, rpm). I’ll try to sum up:

    phpUndercontrol (which is basically CruiseControl) for making sure that everything we put into SVN is proper. It generates docs, runs unit tests, syntax checks and sends us reports if anything fails.

    Then, when doing a release we have a neat script which controls the different Phing build files for various projects. IE: “./build appname release 1.2.1” would invoke phing with the build file for appname. Phing checks out the code from the given release branch in SVN, then checks syntax, runs unit tests, compresses the code and generates a RPM file which is ready to deploy on our servers.


  6. Rsync deployments have been one of the best changes I have made to my release strategy over the last year when moving releases to live. It’s nice to know you have mirror versions of dev/production code bases without relying on pokey FTP upload sessions 🙂

    Also with the remote working distance between myself and the servers (1/2 way round the world) – dealing with inevitable latency whilst using an FTP client became a real pain to handle…

    Like @saad said, database deployments I still handle manually.


  7. You should read the Pear Installer Manifesto by Greg Beaver – its an interesting look on code deployment using Pear.

    I currently use subversion to keep our systems up-to-date – with a set of control scripts to update machines.


  8. wow! excellent – thanks for the great responses. I’ll have to go through these and see what sorts of things might fit our situation best…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s