Tell me more ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.
up vote 1 down vote favorite

We will soon have multiple sharepoint 2010 projects underway. For the first project we brought up two virtual machines - one for development and one for staging. We're about to start another project, and we'd prefer to avoid bringing up an additional two VMs to accommodate this.

Is there a way to host multiple projects on the same VM without compromising developer productivity and project safety?

For example, I've read that the configuration database will be shared, and that multiple instances on sql server still share the same tempdb.

I read this question:

How should I set up my database instances for multiple SP2010 installs?

But this seems to relate only to the database portion of development and staging.

share|improve this question

1 Answer

up vote 2 down vote accepted

Your database server "can" serve multiple SharePoint environments, either by creating unique database names between environments, or by creating a separate SQL instance for each environment. Just because you can obviously doesn't mean you should... your requirements would dictate if that's a viable option.

As for the SharePoint end of things. To my knowledge, one SharePoint server cannot point to multiple SharePoint configuration databases. When you install SharePoint, there are registry keys that point to the database server/instance. In addition, you can't really install the binaries twice, so they'd share the same 14 hive (which pretty much kills any purpose of having a dev box).

In many cases, developers share a VM or run local VM's on their workstations to do development. Those packages get deployed to a staging environment for validation, then to production. There's really no shortcut to a robust testing and deployment process.

That said, why would you need separate environments to develop the two projects? If they're going to ultimately exist on the same production hardware concurrently, then they should coexist in the same manner in Staging. Development, as said earlier, can be done anywhere. Can't you just use the dev VM's from the first project to develop the second one?

share|improve this answer
Thanks. To clarify, these projects are completely unrelated to each other. As an aside, what are you using for local development? We ended up setting up an actual server on a VM, but local development would be nice. Foundation isn't possible in our scenario (features aren't available). I'm looking at VWware workstation and player. Any suggestions? – ScottE Dec 12 '11 at 17:31
I know several folks that use the information worker VM from Microsoft (single VM with SQL, DC, Exchange, Lync and SharePoint). It's a Hyper-V image, but can be fairly easily converted to VM Ware. Most of the people I work with run VMWare workstation on our laptops with our own builds of SharePoint, and all code gets centrally stored in a TFS instance at the office. Development, test and QA happens locally, then the WSPs get deployed to the client's staging environment, tested on that hardware, then deployed into production. – webdes03 Dec 12 '11 at 18:49
Should have mentioned, that our local instances run on VMWare Workstation 7 (we haven't upgraded to 8 yet). Obviously you need a fairly beefy system to run it. We use 8 core (i7) processors and 16Gb of memory in a ThinkPad W510. If you can afford it, a solid state drive, or at least a separate disk for the VMs makes a HUGE difference in performance. – webdes03 Dec 12 '11 at 18:53
Thanks for the input. We're running 8gb or ram - may as well upgrade that. Memory is cheap. – ScottE Dec 12 '11 at 19:02
Yes, 8Gb makes it tough for a VM with a DC, SQL and SharePoint all running. – webdes03 Dec 12 '11 at 19:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.