How to: Deploy an Application on a Virtual Environment
You can use Visual Studio Lab Management to automatically deploy an application to your virtual environment. You can use a specific lab template for a build definition to build your application, and then deploy the application to a virtual environment. This process enables you to set up the latest build of your application in a clean environment by using a known state for your virtual environment. Users can then access the application on this environment, or you can run manual tests or automated tests using Microsoft Test Manager.
Note
If you want to run automated tests after you build and deploy your application, follow the steps in this topic: How to: Configure and Run Scheduled Tests After Building and Deploying Your Application.
Use the following procedures to create the build workflow to build, and deploy your application:
Check the Prerequisites
Create Your Build Definition and Start Your Build
Connect to the Environment from Your Build Results
Note
You can only use the lab template for a build definition with Manual, Scheduled, or Rolling build triggers. Rolling build triggers are not recommended because a test failure still allows the next rolling build to start or stop the entire build system. Gated check-in and Continuous integration triggers are not supported.
Prerequisites
Before you can set up your build workflow to build and deploy your application, use this list to verify that you have completed the following tasks:
Prerequisite Tasks
Configure Lab Management, including a build controller and a test controller: Configuring Lab Management for the First Time.
Create virtual machines for your environment and add the agents to these virtual machines and then store the virtual machines into your library share: How to: Create and Store Virtual Machines and Templates Ready for Lab Management.
Import the virtual machines or templates into your team project from SCVMM: How to: Import a Virtual Machine or a Template from SCVMM.
Create an environment that uses these virtual machines in the required roles and select to run tests and use a workflow for this environment and start your environment: How to: Create an Environment from Virtual Machines or Templates.
Note
You must install and configure any software that is required for each virtual machine for the role that it has been selected for. Selecting a role for a virtual machine does not install any necessary software.
(Recommended) Take a snapshot of your environment to use as a clean state for your workflow: How to: Save the Current State of Your Environment. Before you take this snapshot, follow these steps:
Make sure that the virtual machines in your environment have the latest updates for their operating systems.
Run the command gpupdate /force for any virtual machine in the environment that is connected to a domain to make sure that any changes to user policies have been updated. If you do not run this command, your deployment scripts might not work correctly or your tests might not run correctly.
Check that the state for the environment is "Running" and that the state of the workflow capability is "Ready".
Note
If the virtual machines in this snapshot are joined to a domain and the snapshot is used for longer than the password expiry period for the domain controller, the virtual machines may no longer be able to join the domain. For more information, see How to: Save the Current State of Your Environment.
Make sure that your code projects and test projects for your application are checked into source version control: Placing Files under Version Control.
Create a build definition for your application that you can use to build your application. You can then select this build definition, or select a specific build created by this build definition, when you create the build workflow using the lab template: Create a Basic Build Definition.
Create your Build, Deploy and Test Workflow Using the Lab Template for Your Build Definition
To create your build, deploy and test workflow, you must follow these steps:
Step |
Action |
|---|---|
1 |
Create a basic build definition |
2 |
Create another build definition for your build, deploy, and test workflow |
3 |
Add the details for your workflow |
4 |
Queue the build definition for your workflow |
Create a Basic Build Definition
You must first create a build definition for the code in the application that you want to deploy. If you plan to build your application every time, disable tests in this definition because you will run the tests from your workflow by using the Lab template.
.png "Create a Build Definition for Your Application")
To create a build definition for your application
On the Build menu, click New Build Definition.
On the General tab, in the Build definition name box, specify a name and in the Description text box, add an appropriate description.
Follow the steps as described in the topic Create a Basic Build Definition.
Create the Build Definition for Your Workflow
Next you must create another build definition for your build, deploy, and test workflow, as shown in the following illustration:
.png "Create a Build Definition for Your Workflow")
You must select the LabDefaultTemplate file to create your workflow by selecting to show the details for the build process template, as shown in the following illustration:
.png "Select the build process template for the workflow")
To create a build definition for your workflow
On the Build menu, click New Build Definition.
On the General tab, in the Build definition name box, specify a name and in the Description box add an appropriate description.
Choose settings on the Trigger and Workspace, Build Defaults, and Retention Policy tabs as described in the topic Create a Basic Build Definition.
Note
You do not have to enter a build drop path on the Build Defaults tab for this build workflow because you do not create build output when you use the lab template. Clear My builds copy outputs and no drop folder is required.
To be able to select the Lab Template for the build definition, on the Process tab, under Build process template, click Show details.
A drop-down list appears.
Select a template. This is the build process file that defines your workflow.
To create a workflow for your build definition to deploy your application to a virtual environment, select LabDefaultTemplate.xaml from the drop-down list for Build process file.
Add the Details for your Workflow
Now you can add the details for the workflow process, as shown in the following illustration.
.png "Add the details for the workflow")
The Lab Workflow Parameters wizard takes you through the information that you must provide.
.png "Lab Workflow Parameters Wizard")
You can now queue this build to run your workflow and view the progress of your build workflow.
To add the details for your workflow
To enter the data for your workflow, under Build process parameters, click Lab process settings and then click the ellipsis (…).
This opens the Lab Workflow Parameters wizard where you enter the information for the workflow.
On the Environment tab, select the virtual environment to which you want to deploy your application.
Note
This environment must be active. If you are using an environment that is stored in the library, you must deploy the environment to make it active. We also recommend that this environment be created specifically for your workflow and should not be used by other users. This will prevent issues in which the environment is currently being used and the build workflow reverts the environment to a specific snapshot, or deployment scripts are run on the environment when another user runs a test.
(Recommended) If you want to have the lab build definition revert the environment to a known state, select Revert to a specific snapshot of the environment and then click the ellipsis (…) to select a specific snapshot.
The Select environment snapshot dialog box is displayed. Select the snapshot and then click OK.
Important
It is recommended that you revert to a snapshot to make sure that you consistently run your tests every time that you build from a known state for your environment. This reduces uncertainty in determining the cause of test failures. For example, another user could have changed the current environment by adding software that could cause the tests to fail.
Click Next.
If you want to use this workflow definition to build your application every time that you queue this workflow definition, follow these steps:
Select Use a Team Foundation build, and select the definition that you created earlier.
Select Queue a new build.
If you want this workflow definition to use an existing build and not rebuild your application, do the following:
Select Use a Team Foundation build, and select the definition that you created earlier.
Select Select an existing build. Then select a build from the drop-down list. The existing builds created by the build definition that you selected are displayed in the list.
Select a build configuration from Select build configuration.
Note
The build configurations are specified when you create your build definition for your application. If there is more than one build configuration, you can select one from this list.
If you want to define the location of a build, select Use a build from a specified location and then specify the UNC path of the existing build.
Click Next.
To deploy the application as part of your workflow, from the Deploy tab select Deploy the build.
To add the scripts or commands required to deploy your application, click Add. Select the virtual machine that you want to add the script or command for.
You can now add scripts or commands for each virtual machine in your environment. For example, if you have a Windows client as part of your application, you might have a script that copies the executable to the location that your coded UI test will use to start the tests on your virtual machine. If you have a Web server then you will have to run the script or command to deploy that part of your application.
The following variables are available for you to use with your scripts:
$(BuildLocation): This is the location of the build. If you specified to use the build from a shared location, then this variable represents that path. For the other options, this is the full path for the build based on the configuration that you selected to build and the build drop location in the build definition. If you build your application as part of your workflow, you can use this to access the latest files that were created by that build.
$(InternalComputerName_<VM Name>): This is used to obtain the computer name for a virtual machine that is part of a virtual environment. You might know the virtual machine name, but not the computer name. If you have a deployment script to set up a Web server that requires the computer name, you can pass this as an argument to the script. For example, if the virtual machine name for the Web server was VM1 and the computer name was MyWebServer, you would type $(InternalComputerName_VM1) as the argument for your script and this would pass the value MyWebServer to your script.
$(ComputerName_<VM Name>): This is the fully qualified domain name of the virtual machine. This can be used to access the computer even from outside the virtual environment. You might want to pass this as an argument to set up a Web server. For example, if the virtual machine name for the Web server was VM1, you would type $(ComputerName_VM1) as the argument for your script to pass the fully qualified domain name of the virtual machine.
If you are using network isolation for your environment the value of $(InternalComputerName_<VM Name>) will be the same for the instance of a virtual machine in each copy of this environment, but the $(ComputerName_<VM Name>) is different. For example, the computer name for a virtual machine could be MyWebServer in each copy of the environment but the fully qualified domain name would be unique: VM_<unique identifier>.domain_name.com.
Important
If you want to add a command that is run from a windows prompt, such as mkdir or running a batch file, you must begin the command by using cmd /c. For example, cmd /c $(BuildLocation)\copyexe $(BuildLocation) where copyexe is a batch file copyexe.bat that copies an executable to a local directory on the virtual machine.
If your script or command requires a specific working directory, you can type the directory in Working directory.
Note
Verify that you can run your tests based on the location of files after you deploy your application. For example, if your coded UI test starts a Windows client application, verify that the executable is in the correct directory for the tests to run.
You might also want to verify that the names of the machines in your environment are correct for your application. For example, you might have to verify that the virtual machine for the Web server role is configured to access a database server instance on the virtual machine for the role of database server.
(Recommended) To take a snapshot of your environment after the application has been deployed, but before you run any tests, you must do the following:
Select After deploying the build, take a snapshot of the environment.
Important
If you run this build definition as part of your nightly workflow process, each virtual machine in the environment will soon have many snapshots associated with it. This deteriorates the performance of the virtual machine. In addition, there is a limit of 50 snapshots that can be stored for each virtual environment. Therefore, you must delete the old snapshots regularly.
In Enter the snapshot name, type a name for this snapshot.
Note
You can use this snapshot to connect to the environment and rerun a test whether you want to investigate an issue. Or, another member of your team could do this. It can frequently be useful to have this snapshot to rerun a test on a clean system with the application installed to determine what occurred, or even to verify that the application was installed correctly.
Click Next.
Click Finish.
Click Save to save your build definition.
The created build definition appears in the Builds folder in Team Explorer.
Queue the build definition for your workflow
You can now queue this build to run your workflow and view the progress of your build workflow.
To queue the build definition for your workflow
To start the build definition to build, deploy, and test your application, right-click the lab build definition in the Builds folder and then click Queue New Build.
The Queue Build dialog box is displayed.
Verify the information for your build workflow and then click Queue.
The Build Explorer view is displayed.
To see the Build Summary view as the build progresses, double-click your build.
You can see the status as the build progresses.
(Optional) If you want to view the environment as the build progresses, open Microsoft Test Manager, locate the Lab Center, click Lab, and then click your environment in the list. You can view the progress of the build reflected in the image for your environment and in the environment details above this image as follows:
The snapshot is restored if you selected this option.
The post-deployment snapshot is taken if you selected this option.
The status of the capabilities (a green arrow is displayed when a capability is ready).
The tests as they run, if the tests interact with the user interface.
If your build workflow is completed successfully, you will see a green check mark . If there are errors, you can click View Log to see details.
Connect to the Environment from Your Build Results
You might want to connect to your environment to try your application after the build workflow process is complete. You can connect to the post deployment snapshot, if you selected this option in your build workflow, or to the environment in its current state, as shown in the following illustration.
.png "Connect to the Environment from Your Build Results")
To connect to the environment from your build results
From the Builds folder in Team Explorer, right-click your build workflow definition and point to View Builds.
The Build Explorer view is displayed.
To view your completed build, click the Completed tab.
Double-click the build that you want to view.
The Build Summary view is displayed.
Click the link next to View environment snapshot <Build name and number>.
The Connect to environment dialog box is displayed.
If you want to connect to the snapshot that was taken after the application was deployed, click Connect to the snapshot in this environment.
Note
By connecting to this snapshot, any changes that were made after this post-deployment snapshot will be discarded. If you want to keep any changes, connect to the environment in its current state and take a snapshot first, before reverting to the post-deployment snapshot. For information about how to take a snapshot, see How to: Save the Current State of Your Environment.
If you want to connect to the environment in its current state, click Connect to the environment in its current state.
Click Connect.
The Microsoft Environment Viewer is displayed and you are connected to the environment. You can now use the application that you deployed.
See Also
Concepts
Testing Using Virtual Environments