Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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

share|improve this question
add comment

4 Answers 4

up vote 2 down vote accepted

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.

share|improve this answer
    
im with u mate. Thats how we roll as well –  Anders Rask Dec 16 '10 at 21:21
add comment

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.

share|improve this answer
    
Shared QA farm and CI build is a good idea, but the premise on those farms is basically Visual Studio isn't installed there, the only things that touch that farm are the WSPs and build scripts. –  James Love Dec 15 '10 at 12:27
add comment

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.

share|improve this answer
    
Also if one of the farms are shut down, at least in SP2007, this could break the package deployment completely. I wouldnt touch a shared dev environment with a ten-foot pole! –  Anders Rask Dec 16 '10 at 21:24
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.