Development Environment layout using Linux, Apache, PHP, and Subversion

Some of the age old questions I face lately are:

• What's for dinner?

• Should I accept that friend request on Facebook for the friend of a friend of a friend that I knew 15 years ago?
• What's the best development and test environment layouts for PHP using Apache as a web server with Subversion for version control for multiple developers?

Some of you may be asking yourselves the same questions.  The choice of dinner is a personal one.  I won't go into that except to say that everyone loves a good burrito.  Spicy!  And you probably don't care about my take on Facebook etiquette since your friends list probably dwarfs mine.

But I do have some definite thoughts on the layout of development environments.  And I find that there's a huge lack of information about this on the interweb, so here you go.

We use Linux, Apache, PHP, and subversion in our development environment and so these instructions will be biased towards these topics but I think you can apply this method using various other technologies.

I like to give each developer their own development web site and development database.  I find it's easier for everyone to have their own individual sandbox to play in.  We give them each their own domain using their initials, something like rzdev.domain.com for me and vbdev.domain.com for another developer, Vinny Bag-o-Donuts.  We set the Apache directories up on the Linux dev box in a similar fashion:

/var/www/rzdev.domain.com/
/var/www/vbdev.domain.com/

This has a few benefits.  If I need to show Vinny something with my site development, I can just send him the link to http://rzdev.domain.com/broken-page.  I can make changes to code, even major infrastructure code and not break anything for the other developers.  We do the same thing with the databases, prefacing them with our initials.

Now, since our dev boxes use Linux, we set up Samba for sharing on these web directories.  This means that all the devs can edit files and use source code management on the Linux server itself or on their Windows machines (we use either Eclipse or Zend Studio and create projects on the shares, that's a whole different posting!).

This dev site layout is closely linked to the way we use Subversion for version control.  When we start a new site or application, if we can split out the development evenly enough, we'll just have everyone work from the trunk version of the code, with each developer working on their own little section. Each developer puts the trunk in their Apache dir and we edit the Apache configs to reflect this:

/var/www/rzdev.domain.com/trunk/
/var/www/vbdev.domain.com/trunk/

The root of the dev sites typically look like this:

/var/www/rzdev.domain.com/trunk/docs ( your Apache document root )
/var/www/rzdev.domain.com/trunk/lib ( non-public PHP library code )

When we commit code changes in Subversion, we have a hook that updates our main development site here:

/var/www/dev.domain.com/trunk

Again, that site can be seen on the web at http://dev.domain.com/  This way, we can do integration testing on our code to make sure our new code doesn't break code from someone else within the dev site.

Now, the important thing here is that the Quality Assurance (QA) and Testing people ( if you're lucky enough to have them ), don't use any of these previously mentioned sites for their testing.  Why not?  Well, because if they're doing a good job and are therefore sufficiently anal, they're going to complain when code is changing on the site they're looking at.

So we give them their own test site and database that's viewed on the web at http://test.domain.com/ and setup in apache at:

/var/www/test.domain.com/trunk/docs
/var/www/test.domain.com/trunk/lib

The developers will meet and create the list of files and database changes that get moved over to the test site.  How the actual moving is done doesn't really matter.  If you have the time and energy to set up some Ant or Phing tasks, that works great.  But copying/rsyncing files and running some SQL on the test database works just as well.  The most important part is that the developers meet to decide which part can go to test.  Otherwise, you could have code going to test and eventually production that might not be fully vetted.

When QA finds bugs in test.domain.com, they can send them to the developers.  The developers can instantly start working on fixing the bugs in their own dev space at rzdev.domain.com and not affect the other developers or the ongoing testing of the application.  Pretty nice right?

Advantages of this approach

• Uses source code management
• Developers can unit test their own code
• Developers can do integration testing between each other's code
• Developer A typically doesn't destroy code or data that developer B is using
• Developers don't destroy code or data that QA/testing is looking at
• Developers can both edit files and use source code management in either Linux or Windows environment
• Very scalable.  Adding new developers into the mix is as simple as adding their respective sub domains and databases (of course, this can also be viewed as a disadvantage, see below)
• Less bugs make it to production

Disadvantages

• Lots of sysadmin overhead initially and with each subsequent domain added.  You have to set up all those developer sites, rzdev, vbdev, etc.  Same overhead when using branching within subversion.  Plus, you have to setup all those databases and setup the config code to connect to the appropriate database for each developer domain.
• Lots of file space for all the sites and databases.
• Confusing for lone wolf and gunslinger developers who are used to overwriting production or each other's development code (too bad for them!)

So what do you think?  How do you setup YOUR PHP development environment?

..