Topic: Version Control for multi-disciplined web agency
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)
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.