A few weeks ago I referred to Microsoft’s announcement of Visual Studio 2010 Lab Management, asking if this was Microsoft’s answer to VMware Stage Manager and the answer is… sort of.

I don’t know a huge amount about Stage Manager but the basic premise is that it targets release management by placing virtual machine images into a configuration (a service) and then promoting or demoting configurations between environments based on the rights assigned to a user. Images can also be archived or cloned to create a copy for further testing.

Microsoft’s approach is subtly different – as should be expected with a product that’s part of Visual Studio it’s focused on aiding developers to avoid configuration drift and to perform repetitive system tests during the application development lifecycle, leaving the System Center management products to manage the movement of virtual machines between environments in the virtual infrastructure.

The VSTS approach attempts to address a number of fundamental issues:

• Reproduction of bugs. It’s a common scenario – a tester files a bug but the developer is unable to reproduce it so, after a few rounds of bugfix ping-pong, the incident is closed with a norepo status, resulting in poor morale on both sides.  Lab Management allows the definition of test cases for manual testing (marking steps as passes/fails) and including an action log of all steps performed by the tester.  When an error occurs, the environment state can be checkpointed (including the memory, registry, operating system and software state), allowing for reproduction of the issue.  A system of collectors is used to gather diagnostic data, and, with various methods provided for recording tests (as a video, a checkpoint, an action log or an event log), it’s possible to automate the bug management and tracking process including details, system information, test cases and links to logs/checkpoints – all information is provided to the developer within the Visual Studio interface and the developer has access to the tester’s environment. In addition, because each environment is made up of a number of virtual machines – rather than running all application tiers on a single box – so-called “double-hop” issues are avoided whereby the application works on one box but issues appear when it’s scaled out. In short: Lab Management improves quality.
• Environment setup. Setting up test environments is complex but, using Lab Management, it’s possible for a developer to use a self-service portal to rapidly create an new environment (from a template (not just a VM, but the many interacting roles which make up that environment – a group of virtual machines with an identity – for example an n-tier web application).  These environments may be copied, shared or checkpointed.  The Lab Environment Viewer allows the developer to view the various VM consoles in a single window (avoiding multiple Remote Desktop Connection instances) as well as providing access to checkpoints, allowing developers to switch between different versions of an environment and, because multiple environment checkpoints use the same IP address schema, supporting network fencing.  In short: Lab Management improves productivity.
• Building often and releasing early.  Setting up daily builds is complex and Lab Management’s ability to provide clean environments is an important tool in the application development team’s arsenal.  Using VSTS, a developer can define builds including triggers (e.g. date and time, number of check-ins) and processes (input parameters, environment details, scripts, checkpoints, unit tests to run, etc.).  The traditional build cycle of develop/compile, deploy, run tests becomes develop/compile, restore environment, deploy, take checkpoint, run tests – significantly improving flexibility and reducing setup times. In short: Lab Management improves agility.

From an infrastructure perspective, Lab Management is implemented as a new role in Visual Studio Team System (VSTS), which itself is built on Team Foundation Server (TFS)Lab Management sits alongside Test Case Management (also new in Visual Studio 2010 – codenamed Camano), Build Management, Work Item Tracking and Source Control.

Vishal Mehotra, a Senior Lead Program Manager working on VSTS Lab Management in Microsoft’s India Development Center, explained to me that in addition to TFS, System Center Virtual Machine Manager (SCVMM) is required to provide the virtual machine management capabilities (effectively VSTS Lab Management provides an abstraction layer on the environment using SCVMM). Whilst it’s obviously Microsoft’s intention that the virtualisation platform will be Hyper-V, because SCVMM 2008 can manage VMware Virtual Center, it could also be VMware ESX.  The use of enterprise virtualisation technologies means that the Lab Management environments are scalable and the VMs may be moved between environments when defining templates (e.g. to take an existing VM and move it from UAT into production, etc.).  In addition, System Center Operations Managers adds further capabilities to the stack.

Whilst the final product is some way off and the marketing is not finalised, it seems likely that Lab Management will be a separate SKU (including the System Center prerequisites).  If you’re looking to get your hands on it right now though you may be out of luck – unfortunately Lab Management is not part of the current CTP build for Visual Studio 2010 and .NET Framework 4.0.

This post really just scrapes the surface (and, as I’m not a developer, that’s about as far as I can take it).  To find out more, read about Lab Management in VSTS 2010 over at Somasegar’s Weblog or check out the video of the PDC 2008 session on improving code quality with VSTS 2010 Lab Management, presented by Principal Program Manager, Ram Cherala.