SharePoint development environments, my guidance

At most conferences or events I get cornered by at least two or three people wanting my opinion on how to best set up their development environments.  Questions like:

  • Should I have all my developers on one shared SharePoint server?
  • Should I virtualize?
  • What spec PCs should I buy our developers?

Here is my guidance in its simplest form, in order of preference:

  1. Locally virtualized instance of SharePoint developer environment for each developer. (either Hyper-V or other, not a debate for this post).
  2. Centrally virtualized instances of dev environment.  Still one per developer.
  3. Locally installed SharePoint developer environment “on the metal” with Windows Server 2008 R2.
  4. Locally installed SharePoint developer environment (on the metal” with Windows 7.

“Why virtualize?”   That way you can snapshot, rollback, have different projects in different VMs etc…  There is nothing less productive than having to spend a morning re-building your development environment if you break it.

“Why Windows 7 last?”  We enabled installation on Windows 7 primary for people who were not allowed or didn’t have access to virtualization technology & secondly people who couldn’t install a server OS on their developer workstation for whatever reason.  I prefer to develop on bits that are as close to production as possible and therefore I would try and develop on Windows Server 2008 R2 first.  Dev on Windows 7 is a great experience, don’t get me wrong, its just I would prefer to use a server OS first. YMMV.

“Why not have everyone on one server?”  Productivity.  Having everyone on one server is nasty for a variety of reasons, including but not limited to:  stomping on each others toes with changes by mistake, limited debugging or only one person at a time, versioning issues and dependency management.  It is just so much more productive to have each dev on their own instance of SharePoint and share code and assets around using a source control and build system like TFS.

“What spec machine should I use?”  My guidance is to buy a quad core proc or greater with 8GB of RAM.  Hard drives are VERY critical you should get the fastest you can buy, 7200 RPM min. SSDs in my experience are the single best way to improved your SharePoint development experience.  I would rather have a fast SSD over 16GB of RAM any day.  We use them in our demo laptops and it makes them scream.   Tip: Run the host OS off your slower spinning disk and run your VMs of the SSD. 

Vesa did a good write up on this topic a while back.  It has much more in depth commentary on the subject:

Information on setting up SharePoint on Windows 7 is available here:

Our Patterns and Practices team recently released an updated set of guidance for SharePoint.  In there is a ton on building apps for SharePoint.  Check it out.



Comments (2)

  1. Hey Chris,

    How do you feel about the Developer VM being joined to the domain.  In most testing scenarios you cannot get all the data and other systems into a single VM that is self contained, but putting a VM on the domain, leads to conflicts in computer names etc.

    Any advice on the topic?



  2. chjohn says:

    Hey Cornelius,

    If you do your developer VM right then you wont face issues with adding it to a Domain.  

    To make sure you dont have conflicts you need to sysprep the VM.  Then you wont get name or SID conflicts.  However, as you may know some products dont play well with sysprep.  SharePoint for example can be installed, but not configured and it will survive a sysprep.

    Someone who knows how to build Windows images for corporate deployments should be involved to make sure these issues are addressed.

    The best way to deal with this is to have as much installed and ready possible in the sysprepped image.  Then use PowerShell on first boot to finish configuring the machine.

    Just taking a full built out VM and sysprepping it wont work.