Running Build-Deploy-Test workflow on physical environments
UPDATE: In Visual Studio 11, we have introduced rich support for creating physical environments (called as Standard Environments) and running build-deploy-test workflows on them. Check this blog post for details and to get started: http://blogs.msdn.com/b/lab_management/archive/2011/11/12/lab-management-walkthrough-using-visual-studio-11-developer-preview-virtual-machine.aspx The below article still holds good for Visual Studio/Team Foundation Server 2010.
DISCLAIMER: The information in this post is provided “as-is”, we make no guarantees that the steps will work reliably, and we will not provide any support or upgrade for the definitions you create using the steps described here.
Lab Management feature in Visual Studio 2010 enables automation of the build-deploy-test cycle. This scenario is supported only on virtual environments managed by Lab Management in the current release. This post talks about how this capability can be extended to run workflow on physical machines, with some limitations.
1. Create a physical environment comprising of the machines on which you want to run the build-deploy-test workflow.
Note: In Microsoft Test Manager, you’ll see the Workflow capability status as ‘Not Configured’ for all physical environments. This is OK and your workflow can still run if you follow the steps in this post.
2. Install the build service and configure a build agent on each of the machines in this physical environment. Configure all the build agents with one build controller.
Note: Do not install lab agent on these physical machines.
3. Add a tag to the build agents you configured in step #2. You can do this either from the Team Foundation Administration Console on the build agent machine, or from ‘Builds -> Manage Build Controllers’ in Visual Studio. If you do not do this, the build definitions authored using the ‘Default Template’ (to build your code) may pick this agent to run your builds (the default matching criteria is agent with no tags) – and this might not be a desirable behavior.
Steps to setup and configure the workflow
1. Download the attached zip file, extract the workflow template ‘BuildDeployTest-physical.xaml’ and check-in to source control (example: $/<projectName>/BuildProcessTemplates).
2. Follow the steps to create a build definition described here. Instead of choosing LabDefaultTemplate.xaml, choose the template that was checked-in in the above step.
Note: If the new template does not appear in the drop down, click on the ‘New’ button besides the drop-down, choose ‘Select an existing XAML file’ option and browse for the new template.
3. This definition should be run only on the build controller to which the build agents are configured.
4. Following are the important arguments to be specified for the workflow.
a. ‘Build: New Build’ section (Fill in this section to queue a new build)
- Build Definition Name: Name of the build definition to be queued.
- Configuration: Configuration of the build to be used for deployment and testing (ex: Debug, Retail)
- Platform: Platform of the build to be used for deployment and testing (ex: x86, x64)
- Queue New Build - Indicates whether new build should be queued.
b. ‘Build: Pick Existing Build’ section (This will be used only if new build is not queued)
- Build Location - Path from which the build should be picked up
- Build Number - Value that identifies the build. Typical format is BuildDefinitionName_Date.Revision. This is used to associate the test run with the build. This argument is optional.
c. ‘Deployment’ section
- Deployment Scripts – List of scripts that perform the deployment. Each script is of the format BuildAgentName # PathToExecutable # Arguments
Example 1: Agent1 # $(BuildLocation)\install.exe # /q
Example 2: Agent2 # cmd.exe # /c copy $(BuildLocation)\install.exe C:\installer
- BuildAgentName – name of the build agent on the machine where the script should be executed. You can check the build agent name from ‘Builds -> Manage Build Controllers’ in Visual Studio.
- PathToExecutable – file path to the executable that needs to be executed. This can contain the macro $(BuildLocation) which will be substituted by the value of BuildLocation workflow argument.
- Arguments – arguments to be passed to the executable. $(BuildLocation) macro is allowed.
2. Run deployment scripts – Indicates whether deployment should be performed.
d. ‘Test’ section:
- Test Environment Name – Name of the physical environment
- Test Run Parameters – Identifies the test suites whose test cases should be run along the required test configuration and test settings.
- Run tests – Indicates whether tests are to be run.
The limitations compared to LabDefaultTemplate.xaml are:
1. Ability to pick the latest successful build. This template supports queuing a new build and picking the build from a share, but not picking the latest build, given a build definition.
2. No support to specify environment variables (the macros $(ComputerName_...) and $(InternalComputerName_...)) and working directory for the scripts.
3. No support for snapshots – Given that snapshots are not applicable for physical environments, this is a difference rather than a limitation.
Refer this article to further customize the workflow template.
We hope you find this info useful. Just to remind you again, the above steps are a work-around that enable you to run the workflow on physical machines. We will not provide any support or upgrade for the definitions you create using the steps described in this post.