How do you manage your build [using Phing] process ?

Question

I'm trying to use Phing to automate :

• running tests
• running DB migrations on each Developer machine [using dbdeply]
• deployment to production when needed

I think it does make sense to add a build folder in my project and put all my build configuration files and db deltas in that folder. and commit all that into the SVN repository. so every developer will get the updated build files when he check-out from svn. and be able to run the build to update his DB with the new changes.

on the production server: I was planning to add another build file there to get the latest Tagged version in svn and perform CSS & JS compression.

---

I was planning to implement continues integration using PHPUnderControl too, so I can keep track of the result of each build and get notified whenever the build fails.

so, do you think this all does make sense, or you do have other better suggestions?

Answer 1

What you say makes sense : it's pretty close to what I often use (sometimes with ant, sometimes with phing, and sometimes with some shell-scripts).

In the build directory, I would have something like this :

build/
    testing/
    development/
    staging/
    production/
    common/

With one build.xml file in each sub-directory -- all including another build.xml file, located in the common directory, the idea being to put as much "common" code as possible in the "common" build.xml file, and to have per-environment specific files, that contain as few xml code as possible.

This can be done with the import task that exists in the last version of phing (not sure it's in the stable version -- I'm using an SVN checkout of phing, to have this one, for the project I'm currently working on).

One thing, though : you say you want to deploy to production from the production server ; I would rather, instead :

• on a "development" server :
  • export from SVN
  • compress JS/CSS and all that
  • create a tar.gz archive
• upload that archive to the production server
• on the "production" server :
  • un-compress that uploaded archive
  • change a couple of symlink to use the new version of the sources (see the answer I gave here, for more informations)
  • update what has to be done in the DB

The idea being to :

• do as few things as possible on the production server
  • just in case something goes wrong
  • and in case, one day, your production server doesn't have access to the SVN server
• to have a physical archive that can be deployed on several production servers

Oh, and, as a sidenote : you have to write some kind of documentation of "how to deploy to production", step by step !

This will be really useful the day you are in holiday and someone else has to deploy to production because of an urgent bug-fix ;-)