Verwenden einer Entwicklungsfarm oder Standalone zur Entwicklung von Standard- und Unternehmensfunktionen von SP2010?

Question

Bei der Entwicklung von Standard- und Enterprise-Funktionen von SharePoint 2010 sollten wir einen Farm oder ein eigenständiges Setup verwenden? Bitte beachten Sie, dass eine ähnliche Frage gestellt wurde, aber dieser Aspekt wurde nicht berücksichtigt. Vielen Dank im Voraus

Answer 1

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.

Answer 2

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.

Answer 3

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.