Well, it only took me 18 months, but I finally got around to cleaning up and publishing the Phing filters we use to automatically transform a static site into one that implements many of Yahoo’s Exceptional Performance Rules. These filters, together with the Apache configurations in the README, implement the process outlined in this talk from php|works 2008:
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.
If we are to do unit testing, then it would be nice to have a simple way to run all the tests at once. And seeing the results in a command line is fine, but it would be nice to be able to generate some pretty reports I could view in a browser. And running coverage tools from the command line to see exactly what we’re testing is fine, but it would be nice to be able to generate coverage reports I could view in a browser. It would be nice to be able to do all these things with one simple command.
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.
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.