You ll usually have two deploy scripts - One that you run locally, which ssh s in to the remote server and then kicks off the remote script.

Your local script might do an svn export, zip the contents and push them (scp) to the remote server first. The remote script would do stuff like migrating, restarting services etc.

The basic strategy is that you create a build (well, basically a copy of your web application that you can put online) on your local machine, and then deploy it on the server.

You run it on your local machine and the PHPing will connect to production server and deploy the website. :)

Phing can be applied in many ways.

If you don t have directives on how to deploy, the best way is usually first to generate a "test build" from your local copy, check out if it is working as intended and then generate the productive build.

In some cases where you have to follow certain rules in your development enviroment you can easily adapt Phing to meet those demands.

I developed a phing deploy script and I ve used it in both of the ways you ve described. As long as the phing library and dependencies are installed locally or on the remote machine you can do it in both ways, and it s actually a benefit to be able to run it from any of your environments.

Let me elaborate on my experience, but keep in mind that every person lives within the microcosm of the needs and requirements of their own projects/studios so it s possible that what works for me, may not work for other people.

I think deployment is usually so important for a business that it needs to happen in the exact same way every time. When there s a multitude of people doing the deployments, then it s easy for bad habits or procedures to diverge and that s when mistakes can happen. Automated deployments with phng are handy because if everyone is using the same procedure, then there s much lower potential for mistakes. Phing makes it easy to follow strict procedures because all the developers have to do is to run a simple command like "phing deploy" or "phing build" or what have you.

Now going back to your original question, it s also helpful for these procedures to be adhered to on local development machines as well as on staging, testing, production servers because just like people, machines can have small ideosyncracies that differ from machine to machine. With phing, you can develop a script that will have the same results on any of your enterprise machines (depending on the strength and intent of your code but phing lives in a format that makes it easy to meet that ideal). So if you run your phing build from your development box, ideally it has the same effect if you run it from your testing box or your production server. If you can run the deployment the same way on any machine, you can feel confident that any problems that arise after deployment were not a result of your deploy procedures (as they will not differ from when you deployed to your testing or local dev box).

It s really nice to be able to deploy my code to my local machine with the exact same procedure that I use to deploy it to production.

As far as what is the best to do, I say, why not all of the above? If you can run it locally, then you can run it remotely. If the deploy procedures are strong, then the result will be the same.

You can do it both ways. You can run the tool locally as you develop to run tests and just generally ensure that your code is in good condition. The server automation (if you choose to do that) can also run tests, generate documentation, and deploy changes to test or production setups.

Doing it locally reduces the chance that the process will get stalled on the server setup, while the CI works on a regular basis to ensure nothing has been broken via mistake.