The End to End (E2E) workflow of Visual Studio Lab Management 2010 helps you to automate the complete process of build generation, deploying generated build on a virtual environment and testing the build. I shall refer this scenario as Build-Deploy-Test scenario. Your Build-Deploy-Test scenario might have different requirements like picking test binaries from a location other than build location etc. To do this, you will have to customize E2E workflow template as per your requirements. Here are few tips/steps to customize E2E workflow template. I will use following two simple customizations to demonstrate this:
- To specify test binaries location other than build location.
- To support application installers requiring reboot after deployment.
General Steps before starting customization of E2E workflow template
- Go to "Source control" in VS Team explore.
- Workflow process templates are available at "$/<Project_Name>/BuildProcessTemplates". Map this folder to a local folder say: c:\Beta2 and get the latest version of "LabDefaultTemplate.xaml".
- Make a copy of "LabDefaultTemplate.xaml" and give it a new name say: LabDefaultTemplate_customize.xaml
4. Add this new file to source control. Double clicking on this new file will open it in Visual Studio Workflow editor. Now it is ready for customization.
Customization to specify test binaries location other than build drop location:
In E2E workflow template, test binaries location is assumed to be same as build drop location. You might have a scenario where test code is not built along with the product code and you may want to customize the template such that test binaries are picked up from a different location other than build drop Location.
This customization involves two simple steps:
- Defining a workflow in-argument to specify test binaries path.
- Click on the Arguments tab at the bottom of the workflow editor window, highlighted in the picture below:
- Add a new argument called "TestBinariesLocation". It’s direction is "In" and type is "String".
2. Passing this argument value to ExecuteRemoteTestRun Activity. This activity creates a remote test run, waits till the test run completes and updates build information with test run statistics.
- Go the ExecuteRemoteTestRun activity. It’s display name in LabDefaultTemplate is "Running Tests", highlighted part in picture below.
- Right click the activity and click on "Properties". It opens up properties window towards the right hand corner. It shows in and out arguments of this activity.
- One of in-argument of this activity is “TestDirectory” which corresponds to test binaries location. Click on "TestDirectory" square tab (highlighted below) and change the value to "TestBinariesLocation" value.
Now, check-in this customized “xaml” file and use it to create a new build definition. Below picture shows one such build definition. The new in-argument “TestBinariesLocation” shows up under “Misc” section and you can assign a value here.
Customization to support application installers requiring reboot after deployment:
In E2E workflow template, virtual environment is not restarted at the end of application deployment. You may want to customize the template to support applications, which might require a restart after deployment. Typically, only the virtual machine on which application is installed will be restarted. However, Visual Studio Lab Management 2010 doesn’t support operations on individual virtual machines of an environment. Hence, to achieve this entire virtual environment needs to be restarted.
NOTE: Please ensure that deployment scripts never reboot the virtual machine. If this happens build agent running deployment script will loose connection with controller and workflow might hang.
This customization involves adding three activities to the LabDefaultTemplate that accomplish the following sequence of actions:
Stop the environment
Start the environment
Wait for the machines to boot up before continuing with the rest of the workflow.
In workflow editor, click on the Toolbox tab to see all the Team Foundation LabManagement Activities.
1. To stop the environment, drag the StopLabEnvironment activity and insert before an activity with display name “Application Deployment Succeeded”.
- Right click and select properties for this activity. It shows in/out arguments for this activity.
- The workflow already has a variable called labEnvironmentUri which refers to environment Uri. Click on Variables tab at the bottom of workflow editor to see variables.
- Use this variable to initialize the “LabEnvironmentURI” argument of StopLabEnvironment activity.
2. To start the lab environment, drag and drop StartLabEnvironment activity after StopLabEnvironment activity. Fill in-arguments( Similar to StopLabEnvironment activity )
3. Use Delay activity to add wait for virtual machines to boot up. This activity can be found under Primitives tab of Tool box. You have to fill the duration of wait time like 10 minutes etc. Duration can be specified as TimeSpan.FromMinutes(10).
Check-in this modified template and create a new build definition using this modified template to deploy applications that require restart after reboot.
NOTE: Another more elegant approach to handle restart after installation is to develop a new activity called "RestartLabEnvironment" activity. In my next post about writing custom activities, I will describe how to create this activity and use it.