SP2010 Developer Farm with a Shared Config Database. Viable?

Question

I've setup a small development farm with 3 machines. 1 physical machine running SP2010+SQL server and 2 VM's which were added to the physical machine's farm, all sharing the same config database.

Is this a viable setup for a small team to do SP development or does every machine need to be a closed, standalone setup running both SP & SQL?

Is there a definitive document anywhere that describes how to correctly setup a development farm for 2010 that will be accessed concurrently by 2 or more developers? I've seen a wiki site that mentions 2007, and there are a few questions on this site about 2007, but there's very little info for 2010 that I can find.

I'm pretty new to SP dev and trying to understand how to setup this environment correctly is driving me nuts. Please advise, thank you!

Cheers, Bob

Answer 1

During the development lifecycle, it's highly possible for things to go disastrously wrong whilst developing, especially so if you are just learning.

You can corrupt site collections and even bring down an entire Farm if you do something bad (and these are mistakes we all make and learn from all the time).

For this reason, I highly recommend each developer has his/her own development environment, wrapped up in a Virtual Machine with a snapshot of a clean, working environment.

Answer 2

I agree with James in that ideally, each developer has an isolated dev farm.

As well as the reasons James has mentioned you also need to consider the practical implications of making changes to farm-wide solutions that are deployed to multiple web apps (e.g. app pool recycles) that will most likely disrupt productivity.

Having said that, there are times when the use of a shared config database is useful - for example you might have a custom database that references global template IDs (that are farm specific).

In our case we have in the past had a per-developer VM for development, and a shared QA farm that is more tightly controlled to prevent some of the issues James describes.

Answer 3

Have a look at : http://blogs.msdn.com/b/vesku/archive/2010/02/01/sharepoint-2010-team-development-environment.aspx

and : http://www.chandima.net/Blog/archive/2008/06/05/managing-team-based-sharepoint-development-scenarios.aspx

Having individual VM's is probably the best way to go.

Answer 4

Every developer having a web front-end in a shared farm is old school, and is no longer recommended. It didn't even make that much sense in the days of limited memory and 32-bit hardware.

Give each developer a "stand-alone" environment, and have another farm for integration testing which is configured like your production servers as far as possible (and probably virtual to allow rollback to a known state).

Whether to virtualize the dev. environments is another issue. It makes deployment and rollback easier, but I think the big payback is with larger teams where it allows you to spin up a dev. environment very quickly. Don't feel you have to.