Web-development with version control workflow.

Question

Brief:
I work in a 2-men team (we may expand in future).
We've got a web-dev server and we've got a production server.
Currently, when we start development, we start them on localhost, then we deploy them to web-dev (which we have access through a mounted drive) and we submit changes from this "shared" drive to SVN. Final test on web-dev, approval from the top and off it goes through FTP to our production server.
(I can hear lynch coming...)
Yes, I'm aware it's all wrong with sharing files from one location and submitting it from there, but this wasn't such a bad idea back then when I got to know SVN. And now I want to change it.

So, I know basics of version control, and that the way it works now is wrong big time. I've gone through wikipedia and some svn pages, but I couldn't find a perfect solution how it should actually work.

Could some of you well experienced people suggest how this should actually work?

Things I've found out:

• we should work on local copies on our machines
• then we submit changes to SVN.

Things I want to know:

• how do we make web-dev update after SVN commit?
• how to deploy patches to production server? ftp files? is this what you do? or some other clever solutions?
• anything else I should know about web-dev workflow.

Answer 1

Subversion has post commit hooks which allow you to perform actions on a commit.

You could also look at a continuous integration solution like CruiseControl.net or Team City.

Our process is individual developers work on local configurations. We commit to Subversion and CruiseControl.net checks out and builds the system every time one of us commits.

There's a scheduled build for update installer that runs weekly and updates the install on a server that QA use to verify fixes. Once the fixes are verified, someone (manually) applies the update that was applied to the QA server on the production sites.

Answer 2

A model I've used successfully is as follows

• Instead of subversion, use a distributed version control system, like Mercurial or Git
• All the developers have a local repository that they commit to locally during deployment
• There is an additional test repository that all developers push their changes to after are done. This is checked out by QA and tested
• If all is well with the tested repository, it is tagged and then pushed to the production repository

Answer 3

I'd recommend looking at post commit hooks, like nickd suggests. You can even reject a commit, if it fails to build (say you generate HTML files from some 'source' files and if that build fails you can expect the person to fix that prior to a commit).

• how do we make web-dev update after SVN commit?
• how to deploy patches to production server?

Either automatically, via the hook, or you can consider a manual "svn update" on the production machines, which gives you control of when, which revision and so forth to take into use.

The SVN book is great reading. One can read only the relevant sections and come later back for more. Are you using trunk and tags - they are bread and butter for svn usage and release control.

Answer 4

This is how I've been doing it for a few years now.

Dev Server - Located in house, contains LAMP stack, the repository and a working copy. This has the same versions of software as the production server.

Production Server - Has Staging environment with working copy of repo, also has production environment with non-svn version of project (i.e. the live site).

Developer - Has LAMP stack and working copy of repository on their local machine.

Typical process:

Developer updates working copy of project. Works on local copy, when current changes are done and bug-free they check copy back into repository.

Post-commit hook updates Dev Server's working copy. You may want to do this manually, especially if your team starts to grow.

If changes are working on Dev Server then the working copy on the Staging environment is manually updated.

If changes are working in staging environment then we use RSYNC to push any changes from the staging environment's working copy to the production environment.

Obviously this is a very general explanation of what goes on as you'll want to integrate things like unit testing to the process, but I hope this helps.

Answer 5

The way we do it is pretty simple, and being a small team to, you might be able to relate.

• Development is done on the localhost and commited to a branch of the trunk.
• For QA, the branch is merged with the trunk, and the dev environment (which is copy of trunk) just does an svn up
• If everything is good in QA, I do an svn up in the live environment (which is also a copy of trunk) and I'm done.

I haven't done it yet, but this process can be simplified by adding a post-commit hook to automatically update the dev environment (as others have suggested).