Working in a team of multiple SharePoint developers

Question

In a team of multiple developers, what is the best way to set up the development environment?

Does everyone have their own complete install of SharePoint, or share content databases, or something else?

Answer 1

Each developer needs to have their own virtual machine that nobody shares.

This is for two purposes. First, you can work uninterrupted and non-disruptive to the rest of the team. You're not worrying about someone resetting the system or making it unavailable to you. Second, you can deploy what you want or need without affecting others. Maybe you prefer to use Firefox over IE (I do) and the tools it has. Go ahead and install them in your VM. Maybe you come across a web part you want to try out. Install it. Best thing is you can take your own personal snapshot before you install that web part and if things go south, just regress back to the previous version.

Once you've done all your messing around and built your system then package it up as a feature and deploy it to a shared testing/staging environment before moving it onto production.

The only requirement is that your developers have a connection from their VM to your source control system. This is so they can check code in/out and if you're using continuous integration then your build server can grab a copy of the code and update the build. If you work in isolation in your VM, look at something like a robocopy script or SyncToy or similar tool to sync up the contents of your VM to an outside drive that will push your code into the repository.

Answer 2

Great question! Surprised on how we all seem to agree so far. This is usally a subject that can divide people quite a lot :-)

Each developer should have a virtual server instance (be it HyperV or VMWare, locally hosted or shared). Database could be shared, but each developer has his own database instance (using shared environments remotely using VPN is doable but often slows development process down quit alot, and hence should be avoided if possible).

When involved in several projects, each project should have a dedicated set of virtual servers for each developer.

I also like to have a local "POC site" that i can do with what i want. I use it for doing small tests and stuff i wouldnt do on my project development server. If it gets too messy, i can always reload a snapshot.

To avoid "it worked on my box" issues, there should be guidelines on how to develop. Like having the least possible privileges on the box while developing, and especially having only visitor permissions when doing normal web part development or similar.

Development servers should be created by same golden image and same (preferably scripted) zero point configuration as the dev test, integration test, pre prod and prod servers. This will minimize issues in dev test due to special configuration or software issues on the developers server. I even know of developer teams (eg Ben Robb) that delete all their virtual developer servers every week and roll out a snapshot (automated with powershell) of the server to keep development servers as close to dev test (and the other environments) as possible.

Often overlooked is that especially for larger teams you need guidelines on how naming should be (eg. sub folders in root folder (12hive if you like) how to use namespaces etc), how to deploy (BIN + CAS or GAC, and when to use what), usage of common Utility like libraries. Not having cleared this up before startup will cause you grief along the road and increase the risk of having small islands of code that should/could have been reused across the team (or even across projecs if the libraries are good and generic enough).

Answer 3

My take is that everyone should have their own copy of everything. Sharing databases, application pools, servers only makes you make more mistakes or have misunderstandings. Debugging is really awkward and unproductive using shared resources and think about database locks etc

Once the developer(s) are ready the features are moved to a test/staging environment, which is shared. Developers can copy the test/stage env to their development env if necessary to get some real data.

Answer 4

Forcing devs to have their own VM forces them to write code that is deployable to the team membes in their own VMs ;-) it's a cunning disguise for a great end result!

a lot of organisations share a SQL server with different content databases and have individual VMs with SharePoint and Visual Studio etc for each developer. Often these VMs are actually hosted on a shared virtualisation host rather than on developers workstations due to memory requirements etc.

The @SPDevWiki's Building a SharePoint Development Environment on this.