views:

495

answers:

4

We are starting with Sharepoint development with a team of three and are currently setting up our development environments. We would like to avoid installing a Server 2008 for each developer, thus a single terminal server has been setup, using Remote Windows to start a VS2008 instance on each developer's machine. Now we would like to separate developers' testing environments (i.e. a different site colletion per developer), but have realized that the assemblies would need to be installed into GAC to show properly on the site. But since there is AFAIK only one GAC, developers wouldn't be able to test their stuff independently.

Is there any way we could create separate testing environments without installing a bunch of 2008 Servers?

+1  A: 

I don't know about installing the server on everything, but this sounds like an ideal task for Virtual Machines rather than physical ones- where I work we using VMWare a whole lot for this kind of work and it does very well.

It's also useful to be able to roll back to a snapshot when it comes to testing installation processes and so on.

glenatron
Virtual Machines or not, we'd need appropriate capacities and installations. Especially on developer machines using a gig of RAM just to test a couple of thing seems a bit ridiculous to me. There is no real need in several servers in terms of performance, so I'd like to implement this in one server.
rassie
I don't know what your labour costs are - how how many lost hours = a gig of RAM? I've had this running acceptablly with a XP laptop host with 1.25GB ram and a 2003 guest taking 1/2 of the avail ram.
Ryan
+4  A: 

So you're all going to remote in an fire up Visual Studio and be compiling stuff and restarting IIS, etc?

You're going to be stamping on each other's toes.

A wiser choice nowadays is to use Hyper-V (or some other virtualisation).

We use Windows Server 2008 on our laptops, and use Hyper-V to run our dev environments. We then have a dev environment (sandbox) each, and these have VS2008, SVN, Nunit, etc.

Our code is tested against each other thanks to CruiseControl on the only shared Hyper-V.

This has been great for us... we distribute the load, we can work on the move, we don't step on each others toes and if we need to do a demo we can switch Hyper-Vs and demo from the demo Hyper-V (branched from the dev one early on so that the environments are known).

Go virtual and don't look back.

PS: I've just seen your comment about one server... just put Hyper-V on that and run 3 instances. That's also what we do ;)

+1  A: 

No. In addition to the GAC there are all the SharePoint files in the 12 hive, such as features and site templates. It's not worth what you save on server costs.

(Of course if you don't use the GAC, but deploy to the bin folder, and you don't touch anything in the 12 hive, you can give each developer their own web application on the same server. But this approach puts a lot of restrictions on what they can do. It's still not worth it.)

Virtual machines will work, but they can be slow to develop on. For instance, you'll need to restart the application pool for every GAC deploy - which means a pause of maybe 15-60 seconds to reload the application, (depending on the hardware). This will become annoying.

Virtual machines work better for test and production, where you don't restart the application so often.

I recommend a physical server for each developer. This will minimize the code-deploy-test cycle time, and make sure they don't have to worry about stepping on each others toes.

Bjørn Stærk
+1  A: 

You are on the wrong track with Terminal Services - its just not going to give you any separation.

A lot of people do recommend developing on W003/2008 server directly, and it does simplify some things like remote debugging.

I prefer the more traditional method of using VMWare to run virtual machines. These can be running on a local or remote host. Remote debugging is a little more complex to setup but still possible.

Finally - if possible then deploy to the bin dir rather than the GAC. This will make it much easier to deploy automatically after compilation.

Ryan