Team Foundation Server (TFS) 2010: Lab Management FAQ
Posted by: Subodh Sohoni
in Category VSTS & TFS
Abstract: In this article, we will take an overview of the Lab Management feature of Team Foundation Server (TFS) 2010 and Microsoft Test Manager 2010, in a nice Q & A format.
In Application Lifecycle Management, it is desirable that to maintain high productivity of the team, you need to have close integration of tools for testers and developers. Fixing the bugs that are found while testing is a time consuming task. To make bug fixing efficient, it is necessary that developers should be able to recreate the bugs that are found by the testers. It is estimated that about 15% to 20% of the bugs that are filed by testers are not reproducible in the environment that is used by developers. Differences in the environments in which the developers and testers work lead to such ‘No Repro’ state of the bug. This may further lead to inefficiencies of bug fixing and sometimes important bugs may go in the product just because they were not able to be reproduced.
Microsoft has provided a solution for such ‘No Repro’ situations in the form of Lab Management. It uses the advanced virtualization technology that was introduced with Windows Server 2008 called Hyper-V. It virtualizes the testing and staging servers on a Hyper-V host. It has capability
To do automatic deployment of builds on these virtualized testing or staging servers.
Use these servers to do the testing which can be manual or automated.
Take a snapshot of the virtual environment that stores the state of virtual machines in the environment.
Recreate the virtual environment and apply snapshot on those so that developers can view the virtual environment as it was when the bug was filed.
Create multiple instances of same virtual environment by providing network isolation for them.
Create and use preconfigured templates for creation of Virtual Machines that constitute the virtual environment.
What are the advantages of Lab Management?
It reduces the infrastructure cost as it virtualizes the testing and staging servers. These servers need to be deployed to the Hyper-V host as and when required only so that multiple such environments can be hosted on the same Hyper-V host.
Improves the efficiency of bug fixing.
Reduces the friction between testers and developers that gets developed due to ‘No Repro’ bugs. It results in better collaborative efforts that are more productive.
How do the basic features of Lab management work?
Lab management involves running virtual machines of the environment on the Hyper-V host and execution of tests on them through MTM 2010. For more information on MTM 2010 read an article about it on DotNetCurry titled Introduction to Visual Studio Test Professional 2010. When the virtual environment is not required to be deployed on the Hyper-V host, those are stored on the SCVMM Server in a SCVMM library share. As and when they are required for testing or viewing (for bug fixing) they are redeployed on the Hyper-V host for Test Runner activity of the MTM 2010. Link to that snapshot is embedded on the bug work item. When needed, the developer clicks on the link to snapshot which is then applied on the virtual machines of the environment. To learn how to work with Lab Management, check out my eLearning course Using Lab Management with Team Foundation Server 2010
What is the Lab management feature composed of?
Lab management essentially revolves around three servers – Team Foundation Server 2010, Hyper-V host and System Center Virtual Machine Manager (SCVMM). Since TFS is processor intensive, Hyper-V is memory intensive and SCVMM is hard disc intensive, all of them can be placed on one physical box having a quad code processor, minimum 8 GB RAM and minimum 500 GB drive, it is suggested that for production environment they should be on different boxes. All these servers should be in one security domain controlled by an Active Directory. Control of virtual environments of lab management feature is done through the Lab Center activity of Microsoft Test Manager 2010 (MTM 2010). Virtual machines that constitute the virtual environments should have Test Agents and Lab Agents installed on them. If automatic build deployment is to be used, then build agent also should be installed on them.
What are the pre-requisites for Lab Management to work?
We require a Hyper-V host, SCVMM 2008 Server, TFS 2010 and Microsoft Test Manager 2010 (MTM 2010) to be installed for Lab Management to work. Usually in a non-trivial production situation, all of these should be installed on separate machines. Hyper-V host requires a processor that is Hyper-V capable, Windows Server 2008 64 Bit (preferably R2) and minimum about 8 GB RAM. Higher the RAM on that machine, more are the number of environments that it can run. SCVMM server requires massive hard disc space and fast network connectivity to Hyper-V host machine (preferably a gigabit network or SAN). It does not require any special processor to be present. TFS machine should have SCVMM Administration Console installed on it. MTM 2010 is to be installed where the tester is going to do the testing.
How is the installation and configuration of Lab Management done?
We begin with installing Windows Server 2008 R2 on the appropriate machine and enable Hyper-V role on that. Then we install SCVMM 2008 Server and SCVMM Admin Console. Now we create number of virtual machines that may be required for Virtual Environments creation. Then we install TFS 2010 and on the same machine install SCVMM 2008 Admin Console too. Finally we install the MTM 2010 and connect it to the TFS. It is necessary to have all machines under one domain in the Active Directory. Now we are ready for the configuration.
First we configure SCVMM Server to register a Hyper-V host group and add our Hyper-V host in that Host Group. We create a SCVMM Library Share and store all our virtual machines in that share. Then we start configuration of TFS 2010. We first configure Lab Management service of the TFS 2010. We provide the name of the SCVMM Server to TFS. We configure IP address zone for isolation of network in case we want to have that for the virtual environment when we create it. We also provide the URL of the TFS for Lab Management. Next we configure the Team Project Collection for which we want to have Lab Management feature to be turned on. For TPC we configure SCVMM Library share to use, Hyper-V host group to use and credentials of the service accounts. Now we are ready to create Virtual Environments. For these environments to participate in testing, we install a Test Controller and link it with the same TPC that we have configured for Lab Management. On all the virtual machines those will compose the environment we install Test Agent and Lab Agent. If we want to utilize the option of automatic build deployment, we also install Build Agents on those virtual machines. Build controller can be present on the same machine where TFS is installed. To do the walkthrough of configuring TFS 2010 to use Lab Management, check out my eLearning product on Lab Management
How to create Virtual Environments that can be used for execution of tests?
We can create virtual environments in two different ways using Lab Center of the MTM 2010.
1. Create virtual environment from virtual machines or templates of virtual machines stored under SCVMM Library share. We need to first import those virtual machines that are going to be part of the virtual environment so that they are linked with the Team Project that we are going to use for testing. While importing each virtual machine, we have to provide the role it will play in the environment.
2. Compose virtual environment from those virtual machines that are already running on the Hyper-V host. We select and add virtual machines those are available and then provide the role for each of them.
After the environments are created we can either store them on the SCVMM Library in the share or we can start them so that all virtual machines in the environment are running and we can do testing.
How can we use virtual environment for testing?
Once the virtual environment is created and application is deployed on those virtual machines in the environment, we can store them in the SCVMM Library Share. We can now go to the properties of the Test Plan and assign the environment to the test plan. When the tester needs to do testing of any test case which is under that test plan, then the tester deploys the environment on the Hyper-V host. Deployed virtual environments and individual virtual machines are available for testing either through the browser or through the environment viewer which is part of the MTM 2010. A web application can be tested using the browser and desktop application through the environment viewer. When the test is run, diagnostic data can be collected from the tester’s machine and also from the virtual machines that are part of the virtual environment.
How the same environment is made available to the developers for checking the bug?
When tester encounters the error condition during testing, tester fails the test and if the error condition is difficult to reproduce then tester takes a snapshot of the virtual environment. This snapshot is different than the visual snapshot of the interface of the application. It contains the state of each virtual machine as it is when the snapshot is taken.
Tester then creates the instance of the bug which contains the links to the diagnostic data as well as link to the snapshot of the virtual environment (with the extension .lvr). Actual snapshot is stored on the Hyper-V host. Bug is stored as a work item on the Team Foundation Server 2010. Virtual environment may be stored back on the SCVMM server (in the library share). Environment now can be changed as needed for some other testing. A new build may get deployed on the virtual machines of the environment. When the developer opens the bug and finds it difficult to reproduce the bug in the development environment then the snapshot of the virtual environment is used by the developer. Now the developer clicks on the link to the snapshot (.lvr) to redeploy the test environment. The test environment is deployed on the Hyper-V host and snapshot is applied to bring the virtual environment to the same state as it was when the snapshot was taken. Even if the virtual machines of the environment have changed in the meanwhile, developer still gets the same state of those as and when the snapshot was taken. Now the developer can run the application on the test environment to reproduce the bug and find the ways to do bug fixing.
Can we create multiple instances of the same virtual environment and if so, what are the issues related to it?
Multiple instances of the same environment that is stored in the SCVMM library share can be deployed on the same Hyper-V host. Since the virtual machines of the deployed environment behave like any physical machines they are bound by the networking laws. They are susceptible to the warnings and errors if the names and IP addresses are duplicated in the network. To avoid this issue, virtual environments can be created in the isolated network. To do that, when the environment is being configured, we can provide the Isolated Environment capability to that virtual environment. When the virtual environment with Isolated Network capability is deployed on the Hyper-V host, it can neither communicate with the virtual machines that are in the other deployed environments nor with the Hyper-V host and other physical machines. They can communicate with only the virtual machines that are in the same environment. There are certain constraints for this to work. Machines in such isolated network need to be either in the workgroup or their domain controller should be part of the same virtual environment so that the user authentication takes place even if the outside machines are not accessible.
What are the virtual machine templates and how are they used in Lab Management?
Hyper-V provides a capability to store the common configuration of virtual machines including the installed OS, software, assigned hardware etc. in the template form in the SCVMM library. What is not stored is the specific configuration like network address and names of the virtual machines. Using MTM 2010, a tester can create a virtual environment using these templates. When such an environment is deployed on the Hyper-V host, it creates the instances of these virtual machines and applies the specific properties of network address etc. Now those machines are available for doing testing or to run the application.
How can the builds get automatically deployed on the virtual environment?
Team build with MTM 2010 can be used to do the automatic deployment of newly created builds on the running Virtual Environment. This is achieved with the help of a build definition based upon a template that is LabDefaultTemplate.xaml.
This build definition outsources the compilation to another build that uses normal ‘Default’ build. During the build execution, besides calling this wrapped build definition for compilation, it has a main task to execute the deployment script. As a build definition creation it accepts name of the target virtual environment, name of the build definition that will do the compilation and the script names and paths. Scripts can be either .bat files or any other files that can be executed at the command prompt.
Path of the scripts must be on the virtual machines of the target virtual environment. These virtual machines will be doing actual build execution so that they should have ‘build agents’ installed on them connected to a build controller that can be on TFS 2010. As a part of the build process, it calls the nested build to do the compilation and when the binaries are available it picks them up using scripts and copies them to the appropriate location on the virtual machines of the target virtual environment.
Summary: In this article we have taken an overview of Lab Management feature of Team Foundation Server 2010 and Microsoft Test Manager 2010. The advantages of using Lab Management are:
1. Provides easy access to developers to the environment that is used for testing. Efforts for bug-understanding and fixing are reduced.
2. Provides same state of machines and applications to developers as and when the bug was found. Since developers can view the same environment, ‘No Repro’ situation of bug is avoided. This improves the collaborative efforts between developers and testers leading to over improvement in the productivity of the team.
3. Reduces the hardware and infrastructure requirement for staging and testing servers as virtualization technology (Hyper-V) is used.
Learn to setup and use Lab Management by getting an eLearning course at Using Lab Management with Team Foundation Server 2010