Lab Management Scenarios
[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]
As you write and test the code for your application, you have the choice of working in the environments you create on either physical or virtual machines. An environment consists of a set of roles. A role specifies the purpose of a machine in the environment, for example, a Database Server. The environment enables you to run tests, collect data, or perform system actions on machines for each specific role. You can select which machines to use in an environment, based on the properties of each role.
Using Virtual Environments in Developing Your Application
By using Visual Studio Team System Lab Management and Microsoft Test and Lab Manager, you can create and use virtual environments in a variety of development tasks.
If you are developing one or more components of a multitier application, you can use a single virtual environment that contains multiple virtual machines. Each virtual machine constitutes a separate tier of your application. In most cases, you would want a virtual environment to mimic the way the application would be set up in production.
If you are developing a server application that can be deployed in multiple topologies, you could define a separate virtual environment for each topology. For example, you might want to test your server application in two topologies: 1) where the database and application tiers are co-located on the same machine, and 2) where the two tiers are located on different machines. You can then define one virtual environment for the first topology and one virtual environment for the second.
If you are developing a desktop or client application, you can create the virtual environment using a single virtual machine.
You can also define a virtual environment with only some components of the application. Other components are shared across environments. For example, if your application needs a large database, then you can choose to host a shared database on a physical machine. All virtual environments will just have virtual machines for the client and application tiers.
Sharing Environments
The number of virtual environments that you create depends partly on the application life cycle (ALM) your team follows. You might choose to have each team project member create one or more private virtual environments for their day-to-day work and functional testing. Or you might choose to create one set of virtual environments for integration testing and another set for staging new builds of the application. For each bug that is found, the tester could take a snapshot of that environment and store the snapshot in the library. Each developer who needs to look at that bug can create his or her own active copy of that virtual environment. Providing each team project member with one or two of their own copies of the virtual environment enables them to work in parallel and avoid the scheduling problems and data corruption that are common with shared environments.
In an alternative model, you could create a few virtual environments and have them managed by project administrators. These virtual environments are then shared among team project members like physical environments and machines are shared. Although this approach reduces the parallelism, it might be a process that a team is already accustomed to. As the team embraces virtualization and becomes more familiar with the functionality in Lab Management, the team might migrate toward the first model described earlier.
Life Cycle of a Virtual Environment
Generally, a virtual environment undergoes the following stages during its life cycle:
A team project administrator or lead stores virtual machine templates in a team project library share. These VM templates are "golden" images of standard operating systems or operating systems combined with the prerequisite software for the application being developed.
A team project member creates virtual machines from the VM templates, assigns roles to those machines, and groups the virtual machines to create an active environment.
The team project member connects to the active environment and installs all the prerequisite software for the application being developed or tested.
The team project member takes a snapshot of the environment in order to return to this pristine state and install a newer version of the application whenever a new version is needed.
The team project member installs the latest version of the application and makes any post-installation configurations.
The team project member stores a copy of that environment as a golden image in the team project library share.
Each team project member creates a fresh active instance from that stored environment for his or her daily work.
When a team project member finds a bug or needs to temporarily stop working with the environment and resume later, the member makes another copy of the environment and stores it in the team project library share.
This stored environment is as good as the golden environment that was created in the previous step and is available for the same user or other users to be copied again.
When the environment is no longer needed, the team project administrator or lead deletes the environment from the host group and the environment template from the team project library share.
The previous life cycle is not intended to be prescriptive and must be adapted to the needs and processes followed by individual teams.
Organizing Virtual Environments
A team project can be configured to use multiple host groups and multiple library shares for organizational purposes. The following examples show how you might organize library shares and host groups for your project:
One library share for golden virtual machine templates, one for golden stored environments, and one for bugs.
One library share for developers and one for testers or any other grouping of the team.
For performance reasons, virtual machine templates that are used most frequently may be spread across several library shares and servers.