views:

399

answers:

3

Version control systems are obviously important in development projects but there use in web development projects appears to be more complex, what with the requirement of having a web server to run all but the simplest of web applications.

With that in mind, I have looked around and discovered a few different methods of using version control in web development projects:

  1. Provide each developer with a virtual machine which is a replication of the development server and have the developer run their working copy of the application in the virtual machine.

  2. Have each developer use a sub domain on the development server, e.g. john.project.com and checkout their working copy of the app to the directories the sub domain points to.

  3. Use the version control system to checkout code, make a change, commit the code and then check it on the development server (which points to the head of the repository).

I can see a drawback of 1 being the added time required to create the virtual machines and ensure that the virtual machines are kept insync with the development server (also the need(?) to continuously change the developers host file to point at the virtual machine not the development server).

I can see 2 possibly being a problem if absolute URLs are used within the site unless there is an easy way to update the configuration to use the new subdomains as well.

3 is the easiest to set up but is rather primitive and it will presumably become quite tedious for a developer to keep checking in the code after every time change.

How have the users of stackoverflow used version control with web development projects and which method/workflow was most effective.

Please also include extra methods I haven't thought of / read about.

A: 

You seem to have left out another option, which for most ASP.NET .NET developers is common.

4) Pull source code out of repository, develop locally check back in. This is really the same as the VM approach, just no VM. In ASP.NET you either use IIS locally or the Visual Studio development server.

RichardOD
I suppose that is because the situation I was thinking of was LAMP + non-LAMP developer machines.But 4) is probably best for ASP.NET developers.
Adam Taylor
I thought you might of been, though you didn't add any LAMP tags to the question so I gave my answer for completeness. For ASP.NET I've only ever seen 1, 2 or 4 (my 4). VMs are useful if you wish to play with Beta versions of Visual Studio without ruining your main machine and sometimes corporate policy mandates an approach similar to 2. Still an interesting question so +1 from me.
RichardOD
A: 

What you are talking about there is not just version control but also a Build Server.

It depends on what language you are writing in, if it's java than CruiseControl with SVN/Github, if it's c# then Team Foundation Server or CruiseControl.Net with SVN/GitHub

Most version control systems will allow you to branch and merge and then using your Build Server you can deploy that to whatever webserver you like. That should sort out your separate developer subdomains.

Stephen lacy
+1  A: 

Try a combination of 1+3.

#1: Provide each developer with a virtual machine which is a replication of the development server and have the developer run their working copy of the application in the virtual machine.

I don't like VMs - maybe just because I am running the same OS the server is running on. Updating and keeping it in sync is a task I can do by myself (once a week: "just install package XYZ"). Every month or so you might freeze a VM for backup (or to give to new developers).

It's the best method for the developer. He doesn't have to wait for a commit/deploy to happen. Change a line of code, save the file, press F5 in the browser, done. For best efficiency that's the way to go.

#3: Use the version control system to checkout code, make a change, commit the code and then check it on the development server (which points to the head of the repository).

I would really recommend to setup a staging/dev server. Each time somebody commits into Version Control the server should automatically get the newest version and restart the webserver. This way other people can have a look at the running product and give feedback.

Marcel J.
Yes having an additional development/staging server was in mind in addition to having developers use VMs.
Adam Taylor