VSInsider

Visual Studio 2010 Lab Management

• By Brian Randell
• 08/01/2011

A few months after the Visual Studio 2010 family of products was released to manufacturing, Microsoft produced the final version of its new Lab Management product. Originally designed as a separate product with distinct licensing, Microsoft changed its plans: Anyone with either a Visual Studio 2010 Ultimate license or a Visual Studio 2010 Test Professional license (with a qualifying MSDN subscription) can run Lab Management. Naturally the cost savings are great. And of course, if you're a tester, it's a big win. But why would developers care?

First, it's important to understand what Visual Studio 2010 Lab Management can do for a team. Lab Management provides a centralized way to create, manage and share environments in your domain-joined Team Foundation Server (TFS) 2010 development shop. While physical environments have a purpose, the real value is virtual environments.

Virtual Benefits
In this first release, Lab Management virtual environments are made up of one or more Hyper-V virtual machines (VMs). There are steps you can take to integrate VMware VMs, but you're going a bit offroad and not getting great out-of-box support -- maybe next release. Today, you can build your environments to duplicate a variety of configurations: a single workstation implementation running Windows XP, for example, to a complete virtual domain. Lab Management also provides a feature called Network Isolation, which lets you run an environment that's completely separated from your network but accessible to your development team. This means you can closely duplicate the topology of your production environments -- on-premises for internal applications or off-premises for external customers. Once you have environments defined, you can use them for a number of tasks.

As part of the team value, one of the first things I like to do with Lab Management is get a build up and running. Lab Management integrates with the build feature of TFS 2010. With an included template, you can take an existing build and turn it into a build-deploy-test workflow. When you define this new build using a wizard, you define a number of options based on your needs. The first thing you do is tell the wizard what environment you want to use. Next, you tell it what build you want to use. Then you tell it how to deploy that build -- XCOPY, MSI, whatever you can provide a command line to, you can deploy. Finally, you tell it what tests you like to run. The template provided is based on Windows Workflow 4, so you can customize it to your heart's content. The key is once this build is working, you now have a repeatable way to get your application out on a set of machines that can be used for testing and debugging.

Environment Snapshots
Because Hyper-V supports a feature known as snapshotting, during the execution of your new Lab Management build, you can start from a known, good clean state. You can also take a snapshot after deployment but before any tests are run. This means after the build is complete, testers can take a clean copy of the environment -- which can be stored and shared in environment libraries -- and start doing additional manual tests. One of the key values in Lab Management is that it understands how to logically group snapshots for an environment with more than one VM. And this is where it gets good for you, the developer -- you can stop playing metaphorical Ping-Pong with your testers.

Visual Studio 2010 Ultimate includes a feature known as IntelliTrace, which is "TiVo" for developers. You can rewind and fast forward your application's execution stack. You can use IntelliTrace daily in Visual Studio 2010 as you write code, but it's also useful to you when testers use it. The tester finds a bug (yes, I know you write bug-free code, but let's pretend you're having an off day), then he creates an actionable bug, which contains IntelliTrace logs with rich data about what went wrong that you can play back inside Visual Studio 2010 to see where the problem occurred. And here's where it's all money -- the tester can attach a link to a snapshot of the environment to the bug. You can now spin up the environment at the point in time right after the bug occurred to really dig in and find out what's causing the code to not work. That, my fellow developers, is why I love Lab Management. When something goes wrong and it's affected by the runtime environment, I can easily jump to the environment and see what's going on -- whether it's an older version of Windows or possibly a server-based configuration that I wouldn't normally have on my desktop. I find bugs quicker. I spend less time messing with software installations. I get to have a life.