More than one customer has asked me about “Development environment Virtualization”.
Basically this scenario consists in the ability of a developer to log on a “Terminal Server” or run a Virtualized environment and have access to everything he/her needs to work (VS, Office and so on).
I have seen a couple of different implementations and thought I would list them with their pros and cons:
- Remote Server running Windows Terminal Services
- Remote Microsoft Virtual Server
- Local Virtual Environment running on Microsoft Virtual PC
While all of these scenarios are supported some of them have distinct advantages -and disadvantages.
The advantage of a Remote Windows Terminal Services is offers central management and unfortunately it has the drawback of suffering from resource contention. Remember a server with 4 gig of RAM and 10 developers reduces them to less than 400mbs each…pretty frustrating if you are working from a workstation with 1 gigabyte of memory not being used….Very good scenario for lots of occasional/migrant developers
Microsoft Virtual Server offers all the advantages/liabilities of Windows Terminal Services with the added benefits of machine independence portability, instant backup/restore and the ability to have edge scenario installations (like a VB 5.0 development machine). Unfortunately it does one drawback that one feature of profiling does not work using *sampling. (It works with profiling using **instrumentation). Once again great scenario for occasional/migrant developers.
While Microsoft Virtual PC eliminates the -resource contention you also lose the primary benefit of the other two-central administration.
The enviroment VSTS MVP Anthony Borton suggests to his clients is:
In this approach long term/full time developers run a Virtual Enviroment locally with Microsoft Virtual PC. For central administration, short term and fringe development scenarios a Virtual Server is employed. If updates are applied or a developer destroys their local copy all they need to do is bring down a new instance of the virtual hard drive from the virtual server.
*Sampling is a profiling method by which the process in question is periodically polled to determine the active function. The resulting data provides a count of how frequently the function in question was on top of the call stack when the process was sampled.
**Instrumentation is a profiling method by which specially built versions of the profiled binaries contain probe functions that collect timing information at the entry and exit to functions in an instrumented module. Because this method of profiling is more invasive than sampling, it incurs a greater amount of overhead. Instrumented binaries are also larger than debug or release binaries and are not intended for deployment.