We had a prototype for a user-facing service written in PHP.
After some discussion, we decided that we really wanted the Test Driven Development that is so easy in RoR, and even thought we could do it in PHP, as our PHP developers had no experience using any kind of object-oriented or template driven PHP development (the code was totally raw PHP), we decided that we would gradually/incrementally replace the code with Ruby-on-Rails.
The first task was to create an empty RoR application. We set it all up with Capistrano, SVN, etc. and deployed it to a test application server. We setup Apache and Mongrel as normal, and made sure to enable PHP in Apache.
We then copied all of the existing web site into Rails’ public directory, and checked it into SVN. We then deployed again, and took a look at the web server, and lo-and-behold, there was our legacy PHP application.
On our laptops, we want to develop, so we need Apache to get the PHP code running. As described in:
http://www.sandelman.ca/mcr/blog/2008/04/30#starting_local_mysql_database
we had some code that started Apache+Postgresql, and this time we run just the Apache code. I decided that test/cluster/etc was needlessly deep, and I installed things into test/etc instead:
See http://www.sandelman.ca/mcr/ruby-files/embrace/ for files: apache2.conf.in, php.ini.in (a snippet), portnum.sh, runweb.sh.in, shutit.sh.in, and apache.rake.
Place apache.rake into lib/tasks, it has:
Start out (after a raw checkout) with:
This will process the .in files into proper config files for apache. It will find the right modules directories for apache, as this sometimes varies between distros.
Then run:
This will start apache on port 8000 + your numerical userid. This picks a consistent port, but lets’ multiple users run simultaneously if they happen to be logging into a common work machine.
Point your browser at http://localhost:8xxx/ , and you should see your application running. A copy of mongrel can be started under the normal load balancer, setup to run in development mode. We commented that line out as actually, we prefer to have it in the foreground in a window, in case we want to do debugging.
(I have it seperated out because we reused some of this for other kinds of tests, too detailed for this entry)
Then, if your test methods, or perhaps in “def setup”, just call: