To see it in action, first create an VirtualHost pointing to the mysite directory in the project as the web root.  Then run:

% phing optimize

which creates a parallel site in a build directory.  Point your VirtualHost to the new build directory to see the same site with the performance transformations.

You could run this Phing task in a continuous integration process as part of deployment.  You could run it at production deployment time, but it’s probably a good idea to run it at staging time in case it flubs on some CSS or HTML syntax that it is not expecting.

Note that there are other miscellaneous Phing tasks in that github project.  I threw these in there in case they could be of use to other Phing users.

The command: phing.

If you’re familiar with Ant for Java, phing is functionally identical to ant.  With a very simple build script, I can run all the unit tests, and generate test result reports and coverage reports in HTML automatically. Then I can fire up my browser and see if any tests failed, or whether we need new tests.

The following are examples of test results reports and coverage reports.

Phing currently requires PHPUnit for unit testing and xdebug for coverage. Someone would have to write a task to use other frameworks such as SimpleTest.

The phing build file is a first step towards automating builds with a build server. A build server can periodically check the project for changes. If new code exists, it will run tests and generate reports for tests, coverage, lint, anything. It can put all this on the web for easy inspection. It can keep versions of the whole project that be can be readily deployed.  So if we have a staging and production server, and we stick to deploying ONLY bundles from the build server, it can make deployment and maintenance easier.

But it never made sense to me.  It was like there were two people building a house, and claiming that if one person worked on the house during the day, and one person worked at night, it would be faster than if both people worked during the day.  At best, it would be equal effort.  It may even be a little worse because if two people work on it together, they can re-use tools and such, and they each have someone to keep them company.

Looking for some literature on using agile methods with offshore teams a while ago, I finally found someone had put the same thought in writing.

Another benefit of offshore that’s coming up is the use of 24 hour development to reduce time to market. The benefit that touted is that by putting hands on the code base at all hours of the day, functionality gets written faster. Frankly I think this is a totally bogus argument, since I don’t see what adding people does in India that it wouldn’t do by adding them to the onshore team. If I need to add people, it’s more efficient to do it while minimizing the communication difficulties.

Martin Fowler, "Using an Agile Software Process with Offshore Development"