PHP Development Environment (w/ source control and versioning)

jon3k

Right now our development environment consists of a single 1U white box (well, black actually, but you get the idea) redhat fc4 server running PHP 5, MySQL 5, and Apache 2.

We've got 3 development workstations, all running windows (Dreamweaver, Photoshop CS2 and EMS MySQL Manager).

We're desperately trying to come up with some form of versioning and source code control. I'd like to use SVN, but I can't come up with a workable solution for implementing it.

I've come up with 3 ways to do this, none of which are very appealing:

1.) I could just setup a project in SVN, check it out into the webroot on the development server, we could all work on it there (and avoid crushing one another's documents with WebDAV + Dreamweaver), then, check it back in on a regular basis.

Unfortunately, that means that we've got 3 people working against a single "checkout" of the source code.

2.) We could setup apache/php on each developer's workstation, we could checkout the code and run it on our own machines.

Drawbacks include the overhead of the webserver and PHP and the incompatibilities between the development server and our workstations.

3.) I could setup seperate web root's for each developer (along with its own hostname), we could each checkout our own copy, work in our own web root, and check back in when we're finished.

Is there some other cleaner solution to this? I'm sure most people developing in PHP are using SVN (or even CVS) for source control - so how do you setup your development environment(s)?

laserlight

1.) I could just setup a project in SVN, check it out into the webroot on the development server, we could all work on it there (and avoid crushing one another's documents with WebDAV + Dreamweaver), then, check it back in on a regular basis.

Unfortunately, that means that we've got 3 people working against a single "checkout" of the source code.

This is not advisable - it defeats the purpose of checking out in the first place.

2.) We could setup apache/php on each developer's workstation, we could checkout the code and run it on our own machines.

Drawbacks include the overhead of the webserver and PHP and the incompatibilities between the development server and our workstations.

This allows individual developers to test and develop code even when not connected to the development server's network (one of the advantages touted by SVN too, and more so in distributed version control systems). The "overhead of the webserver" includes having PHP installed, and that is reasonable - surely you cannot expect to use the PHP parser locally if it isnt installed?

As for "incompatibilities between the development server and our workstations", consider that the production server(s) may also pose this problem, so the developers should be wary in the first place.

3.) I could setup seperate web root's for each developer (along with its own hostname), we could each checkout our own copy, work in our own web root, and check back in when we're finished.

If the developers will always (or are required to) have access to the development server during development, this may be the best solution. If not, #2 would be better.

jon3k

laserlight wrote:
This is not advisable - it defeats the purpose of checking out in the first place.

I agree 100%.

laserlight wrote:
As for "incompatibilities between the development server and our workstations", consider that the production server(s) may also pose this problem, so the developers should be wary in the first place.

Its possible, but unlikely. This isn't software that would be distributed outside of our organization, and we have complete control over the production environment.

laserlight wrote:
If the developers will always (or are required to) have access to the development server during development, this may be the best solution. If not, #2 would be better.

Yes, they do currently have access to the development server (its all the same LAN). However, I'd like to implement a solution that would allow them to work remotely using VPN if they needed to. Thats why #3 becomes such an attractive solution. Plus we can avoid the issue of the source code being checked out into an unsavory location (like a random PC or their laptops), which could easily be lost or stolen (the former referring to the laptop, the latter the laptop and the source code).

Roger_Ramjet

I thought that DW had version control built in!

jon3k

So what's required on the server to use Dreamweaver's version control?

Roger_Ramjet

Dunno, never touch the thing myself. I do know that it has checkin/checkout and site synchronisation. How you set them up is not something I know myself but you'd get lots of help on a DW forum I'm sure.

MarkR

jon3k wrote:
Right now our development environment consists of a single 1U white box (well, black actually, but you get the idea) redhat fc4 server running PHP 5, MySQL 5, and Apache 2.

Presumably your production environment is (or will be, after deployment) similar to this, software-wise at least?

1.) I could just setup a project in SVN, check it out into the webroot on the development server, we could all work on it there...

Definitely not. You can't usefully work in the same working directory with SVN. Two users cannot share a working directory (although each user can have as many working directories as they like)

2.) We could setup apache/php on each developer's workstation, we could checkout the code and run it on our own machines.

Again, not advisable. The workstations are running a completely different software stack from the production server, so you're bound to run into trouble.

Development servers and production servers SHOULD have the same software stack, if at all possible. If not identical, as close as you can reasonably make it. Windows/Linux is certainly not acceptable.

Drawbacks include the overhead of the webserver and PHP...

No. The overhead is not significant. Developers who are running Dreamweaver etc aren't likely to notice the extra load from Apache / Mysql / PHP on their box, unless it didn't have enough RAM in the first place.

Buy developers enough ram for their workstations - ideally loads.

3.) I could setup seperate web root's for each developer (along with its own hostname), we could each checkout our own copy, work in our own web root, and check back in when we're finished.

Probably a good solution. There's not going to be much danger of software version desyncs if all the developers work on the same machine (albeit in different areas).

Each developer should also have their own database so they don't tread on each others toes their either - these should be kept in sync by whatever schema synchronisation regime you use.

Mark

jon3k

Thanks for the response, Mark. I appreciate your input.

And yes, the production environment is an exact mirror of the development environment.

You also make a good point about seperate databases, just not sure of a good way to keep them synchronized - any recommendations?

I'm a little surprised this particular problem hasn't been solved ad naseum. I've done some searching but haven't turned up anything particularly useful.

TF_TheMoon

You can setup database replication to keep the databases in sync, or take nightly snapshots and rsync the files across.

What we so here is to use Subversion for the control, then the developers check out the code either to their local machines which are configured in the same way or to their home drives on the server to develop. We then have a checked out live version which the domains point to, checked out beta versions and checked out alpha versions. We usea central file to store all of the DNS and site paths that change depending on where the site is running from, which detects the URL being used to determine which configuration to use (live, test, development).

MarkR

jon3k wrote:
You also make a good point about seperate databases, just not sure of a good way to keep them synchronized - any recommendations?

There are a number of techniques. Database replication is not one of them.

The easiest way to start with, it to simply maintain your database structure as a script containing DDL CREATE statements, and each time it changes, each developer drops their database and reloads it from the create script.

However, that is inconvenient, and doesn't work in a production environment where you want to make changes to the structure while keeping existing data.

Normally I have two sets of scripts
- A create script, containing DDL to create the database from fresh (Possibly some INSERTs too to add initial data)
- A set of modification scripts, in chronological order

Each time a developer wants to make a database change, they make the change in both the create script, AND make a modification script for it.

This might be able to be done automatically by using one of the many SQL diff programs to compare the schema of the old and new DBs, and make ALTER scripts for you.

All of these scripts would of course be kept in SVN - when A modify script is no longer needed (perhaps because a subsequent refactoring dropped the table it was modifying), it can be deleted.

Moreover, modify scripts can be deleted once you're sure that they've been run on every instance of the application in existence (Production is usually the last one to be updated, unless some of the developers are on holiday at the time).

It's a pain in the arse, but it's the only real way to sort it out.

Clearly you can't have multiple developers sharing a database, as they'd tread on each others toes - if I dropped a column, and removed all code that uses it, other developers' working copies would not yet have that code removed (until I committed it).

Another minor problem is when you decide to revert some changes, you have to switch back to an older version of the DB - but usually the developers figure this out on a case-by-case basis.

Mark