views:

88

answers:

2

Hello,

I've inherited a significantly sized internal app at the company I work for. It has two parts. One runs on a LAMP server, the other runs on a WAMP server. There is no source control to be seen.

Currently, developers will log into each server via FTP and just directly edit the PHP files that are there. Or log into phpMyAdmin and make changes to DB schema where necessary.

What is the best way to implement some source control into this situation? I'm not very knowledgeable on how to best setup CVS ans SVN. Would all developers need their own "test system"? Meaning, would I have to setup a LAMP+WAMP enviornment for each developer? Or can they would off a central dev server? What is the best way to deploy changes that have been made?

Developers all use Windows. We also use Zend Studio 5.5 for development.

Thank you in advance for any advice.

+4  A: 

It's really not a lot of effort for a developer to have a personal LAMP/WAMP running locally or in a VM. A local dev server is worth having for testing non-live changes in a closely matched environment but it doesn't really scale if all developers are making their changes on that at once.

I'd have all developers committing to trunk in Subversion and then have a stable branch which is automatically (using a post-commit hook) deployed onto the server. Only certain people should have write access to the stable branch to ensure a junior developer doesn't accidentally screw the live server.

Mike McQuaid
Other typical setup is to have one central setup for production and other for testing, ie. 2 instances of WAMP+LAMP. Also I'd add that Subversion is probably the easiest version control system for deployments like this (distributed version control systems would also make sense, but they are harder to teach for old-school developers and CVS is just legacy that everybody is migrating from).
Filip Navara
A: 

That's a horrible way to work on websites, especially with a team. The whole setup should be changed.

The source code should live somewhere else, and then get deployed to the website when it's ready. You could have a script that does the deployment and whatnot (copy the files over ssh, plus any other setup if needed, etc). The point is: no one should ever edit files directly on the production server.

hasen j