When doing development for SharePoint 2010 Standard and Enterprise features, should we use a farm or a standalone setup? Please note that a similar question was asked ,but this aspect was not taken into account. Thanks in advance
3 Answers
When developing anything for SharePoint it is always best to target the closest setup used on the live servers.
If this isn't possible, then usually the standard practice is a single VM possibly with an external database. You can then restore the VM and the database quickly while maintaining application speed. External AD and Exchange server is also a good way to go, creating a centralised hub for testing.
Then you have to decide what sort of solution you are going to use, depending on the features required depends on the feature deployment level.
[edit]
@Ryan & in General, I agree the best productivity is where it is at. My issue has always been around topology issues where complex permissions are involved. For that reason, we use 24GB ram machines and run a virtual farm, one for each developer.
Not all companies can do this, but having a cloned virtual setup of live heavily reduces possible issues further down the line. When you are going into Enterprise development, having something that doesn't run like the live environment can and often does cost you extra time in my experience.
If you cannot run a clone of your live environment for development/testing, then always do try and get as close to the real thing as possible. +1 for the link Ryan.
-
Thanks for the answer;if we chose to use a server farm for development,do you think there exist best practices for building such development infrastructure? Commented Oct 24, 2012 at 12:24
-
Yes there is a standard structure that is used. 2 wfe, 2 app and 2 database, with indexer either running on wfe2 or on a seperate machine. Commented Oct 24, 2012 at 12:34
-
Hugh,your contribute is really appreciated;many thanks. Commented Oct 24, 2012 at 14:59
When developing you should, IMHO, use whatever has greatest productivity for your developers, even if this doesn't match your production servers.
For 2010 Standard this is running SharePoint on their desktop PC (enabling things like quick deploy, easy debugging etc etc).
MSDN - Setting up the development environment for SharePoint 2010
However, when doing testing/staging (stand alone/integration testing, QA, Staging etc) you should then use something that closely matches the production environment.
-
Ryan I agree with you;it is sometimes difficult,however,to find out what really improves productivity of your team without trying different solutions,unless your team is made up of experienced SharePoint Developers(which is not our scenario) I've read the article you mention above;at the end of the article a development farm environment is considered but without coming into details;I just wanted to know which are the best practices when choosing that approach. Commented Oct 24, 2012 at 14:54
-
Keep things simple, local install of SharePoint - will be quickest and easiest way for developers to work without extra un-necessary complexity of stepping on each others toes.– RyanCommented Oct 25, 2012 at 11:58
One problem with a single development farm and multiple developers is debugging.
If one developer attaches a debugger to the IIS instances then it locks out the other devs from loading pages.
Also a dev server invariably has "Bad" and messy code on it including quick checks, proof of concepts, etc.
I've always gone for a single dev server per developer, this can be a virtual machine, a local install or any other method. Mine is a virtual machine on a big hyperV instance. Makes it easy to roll back when something royally messes the VM up.
Having a good working knowledge of the target architecture helps avoid surprises when you come to deploy to a test environment. It just takes a little thought up front in the design.
If your devs aren't SharePoint experts then make sure your applications designers (who write the detailed technical designs) are.
Also ensure you have at least one dev who IS a SharePoint expert who can code-review and mentor the junior devs. It's very easy to get into trouble with inexperienced SharePoint dev, such as not disposing objects, etc.
