次の方法で共有

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: https://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.

Pre-requisites

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)

    1. Build Definition Name: Name of the build definition to be queued.
    2. Configuration: Configuration of the build to be used for deployment and testing (ex: Debug, Retail)
    3. Platform: Platform of the build to be used for deployment and testing (ex: x86, x64)
    4. 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)

    1. Build Location - Path from which the build should be picked up
    2. 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

  1. 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:

  1. Test Environment Name – Name of the physical environment
  2. Test Run Parameters – Identifies the test suites whose test cases should be run along the required test configuration and test settings.
  3. Run tests – Indicates whether tests are to be run.

 

Limitations

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.

BuildDeployTest_Physical.zip

Comments

  • Anonymous
    May 10, 2011
    Thanks. This is just what I needed. I can now trigger builds by a check in but still have the advantage of the results being in MTM. I don't fully understand about the build agents. To make this workflow run I have to have two agents (I didn't give either of them tags). When I try to run this with only one build agent the workflow does not complete and I have to abort it by stopping the build service (it does not respond to a workflow cancellation request). Is that because I have two build definitions (one based on your workflow and my own one based on DefaultTemplate that does the build)?

  • Anonymous
    November 22, 2011
    That's great job, keep doing the good job! I am using VM but this provide good varieties that we may need

  • Anonymous
    April 30, 2013
    In Visual Studio 11, the gui associated with the RunTestDetails object is disabled.  

  • Anonymous
    May 02, 2013
    The DefaultTemplate.11.1.xaml in conjuction with TFS 2012 now supports physical machines.  The xaml in the post currently does not work when loaded in Visual Studio 2012 because the dialog associated with the RunTestDetails object is disabled.  However, you can still use the xaml in this post if it is loaded in Visual Studo 2010, even if you are targeting TFS 2012.  Alternatively, migrate your workflow to be based off of the DefaultTemplate.11.1.xaml.

  • Anonymous
    October 29, 2013
    Can I log all the test case executed in a log file from the definition? I need information like test case id, test case name, test outcome.