Info on setting up TFS2010 and SharePoint 2010 for 10 Developers

Question

I am looking for information on how I can easily setup an environment where I can have about 10 developers working and testing independent SharePoint 2010 projects and having all the source code in TFS2010. I'd like to have TFS accesible to the PMs as well but that's optional. I have 11 VM's to work with but our Security folks do not want them listed in DNS. We are thinking of having 10 VM's each running the same configuration "Contoso.com" and an eleventh running TFS2010. I'm not sure this is the correct design. Some ideas on how I could get 10 developes doing independent SharePoint projects and storing code in TFS would be helpful.

Bismarck

Answer 1

The DNS limitation is going to be a headache for you; it will complicate the use of Kerberos. Using stand-alone SharePoint servers to develop against will likely cause deployment and stabilization issues as well. Developing against a stand-alone server will not allow you to test things like double hops.

Instead of using the VMs as duplicates of each other I would stand up a full domain. Use two of them for domain controllers, a database server, one or two Web servers, one or two application servers, and the TFS server. Deploy it in a manner that most closely resembles the production environment.

To partition the environment for developers, just create individual Web applications in SharePoint. Each developer can code against one or more Web applications on an as needed basis. By doing this you'll be in control of the domain, which in my opinion is just about mandatory for efficient SharePoint development. You can create DNS records when you need them, service accounts, SPNs, etc. The other advantage is that you aren't going to clutter up the corporate domain with a bunch of development based items.

Finally, by using an actual development domain for this you'll be able to test solutions in a more "real world" setting. This will help to mitigate any risk surrounding deployment.

Answer 2

I have some thoughts:

1. Developers will need credentials into TFS for checkins/checkouts and for any other TFS features they need. Your PMs will need credentials too. It is likely TFS will exist in your corporate domain.
2. It is probably a good idea to have all of the VMs in a single domain as opposed to each VM hosting its own contoso.com domain (I'm not clear which way you were thinking, but point this out). This way you can create the same service and user accounts that can be shared between development machines.
3. Your best bet is to create a PowerShell script that will automate the configuration of the farm, and make copies for each development VM. The only change you will need to make is the server name. This way, each server is identically configured and you should be able to verify bugs in different farms
4. Use a SQL alias. Make sure you configure both 32-bit (C:\Windows\system32\cliconfg.exe) and 64-bit (C:\Windows\SysWOW64\cliconfg.exe) aliases.
5. I'm not sure why your security folks don't want to list your VMs in DNS. If this is a policy you cannot change, I suggest creating your own domain with DNS that the VMs join. If possible, have your development domain trust your corporate domain so users in the corporate domain can access your development environments.
6. Is your TFS server going to handle builds? Don't forget the build service.