Version Control for multi-disciplined web agency

Question

Ok, so here's the lowdown. I want to setup a Version Control system and associated processes for my agency and want to learn from the mistakes of others before I leap into it.

I'm looking at deploying subversion from a remotely hosted service (assembla - which will also help with offiste code backups!).

We're an ASP.net web shop with 3 main teams. (approx. 30 people splitt across 3 teams)

Frontend Team - Photoshop, XHTML. CSS, Javascript. Mainly using photoshop for design/creative, dreamweaver for markup and topstyle for css.

Development Team - ASP.net primarily but with some php thrown in for variety and where required. So mainly VS2005 and SQL Server work.

At the moment all teams work from a series of network shares - all directly working on a single working copy of a site. While we're introducing version control and we would ideally have every designer/developer setup with a replica of a live web server on their individual machines, it looks like this is not going to be practical in the beginning (i.e. we've got very skilled frontend developers who just don't have the ability to be setting up full fledged ASP.net applications on their individual workstations. Also seems like overkill for a designer who is not used to working in an ASP.net environment when all they want to do is tweak some CSS or some markup.

This means we're likely to retain the network share structure we currently work with (I know not ideal but have to start somewhere) But we're going to make the copy of the site on the network share the main "working copy" checked out from the repository which people work on in our local deveopment environment.

This will then get checked into our main repository before being deployed to a test server out on the internet and eventually live.

What are people's thoughts on my proposed deployment model outlined above?

Does anyone have any advice as to how to get teams with varying skillsets all working to the same version control processes?

Thanks in advance.

Ed

Answer 1

While far from perfect, you might consider WebDAV

See Appendix C, WebDAV and Autoversioning

Your Front-End team could use Win32 WebFolders, and things will look similar to what they're familiar with - a simple network share, but it is really the SVN Repository.

Your Developers could use their own working copies, using AnkhSVN or another client for their work.

Caveat Emptor, YMMV

Answer 2

cheers Ken G,

that looks interesting.

off to do some research!

Answer 3

I've worked in digital agencies for a long time now and using version control in those places can be quite a battle from time to time. I've noticed that the visual crew (the photoshoppers) are usually not up to using a system like version control. There is some technical knowledge involved and when using a system like it you often must approach your files with a bit more discipline. I've heard the phrase "F@ck this sh*t" on too many occasions with those guys, simply because people didn't have the patience to use it or to learn to use it.

Also, as stated in one of the comments, digital agencies often work with vast amounts of binary data. Having an off-site version control system might not be the right choice - unless you've got a massive pipe going from your office to deal with the capacity. It becomes even worse when downloading backups on a regular basis.

Using version control is of course not a debate. Of course you should use it. What you can do is, and this is what I've done in the past and I'll do it again in the future, get your tech team onto using the system first so they know the ins and outs of it, the quirks etc. Then slowly get bit by bit some of the front-end guys on using it (start with the techie ones and work your way down). Once that's done go on to the designers. Again, start with the seniors and work your way down the food chain. Getting the whole studio to use it on day one is digging your own grave.

On the technical site. Once you get your photoshoppers on to using the system you might want to consider setting up an in-house server. This will make your live easier and the whole process of committing and updating faster with 76 meg photoshop files. It will also improve the adoption rate of the system. Let the front-end guys place the final images or videos used for the project put in the off-site version control system.

Keep in mind that introducing a system like this might take a while. It can easily take up to a year before the whole studio is up and running...

Answer 4

PhotoShop CS and above has Version Cue which is its own inbuilt system for Version Control. I've not tried it with PhotoShop itself but have used it with limited success with GoLive.

Perhaps your designers would be happier to use that as it's already built into a tool their familiar with?

Also, your front-end developers could use Version Cue with Dream Weaver or GoLive for their minor code changes although I don't know if this has any hooks into a "proper" CVS system.

Answer 5

You might want to take a look at Perforce it works great with Visual Studio but also has plugins for Photoshop that make working with version controlled assets simpler.

As far as getting the teams buy in you might also want to take a look at the Streamed Lines paper - is details some best practices and anti-patterns to avoid