Preparing the Deployment Script

Deployment scripts are associated with specific Team Build Types and are designed to be triggered when the build quality indicator transitions from one state to another.

PreparingDeploymentScripts1.jpg

The configuration information which controls whether an instance of TFS Deployer springs into action is stored under version control in a Deployment subdirectory under the directory where the corresponding build process template is located. For example, for a build definition called "Foo.Nightly" using the default build process template in Team Project "Foo", the path that TFS Deployer will look for its configuration and scripts will be "$/Foo/BuildProcessTemplates/Deployment/".

As another example, for a build definition called "Bar.Nightly" using a custom build process template stored in a "Build" subdirectory under the "Bar" solution directory in Team Project "Bar", the path to the Deployment subdirectory would be "$/Bar/Trunk/Bar/Build/Deployment/".

Build process templates can be shared by many build definitions (especially DefaultProcessTemplate.xml) so each <Mapping> element in a DeploymentMappings.xml file has a "BuildDefinitionPattern" attribute which is a regular expression to constrain a mapping to apply to only particular build definitions. For example, a BuildDefinitionPattern value of "^Foo" would match a build quality status change for build definitions "Foo.CI" and "Foo.Nightly" but would not match "Bar.Nightly" or "SomeFoo.CI".

TODO: replace the obsolete screenshot below.

PreparingDeploymentScripts2.jpg

The DeploymentMappings.xml file quite simply lists out which script to execute, for which build definition, and on what computer when a build's quality transitions between two states. It also lists the email address to send a notification to when the script succeeds or fails, and other details. The TFS Deployer release download includes a sample DeployerMappings.xml file. TODO: replace the obsolete screenshot below.

DeploymentMappingFileScreenShot.jpg

When TFS Deployer is notified of a build quality status change, it will download the mapping file corresponding to the build definition's build process template and look for a matching mapping. If a match is found, it will download the rest of the files contained in the Deployment directory to the TFS Deployer machine and then execute the script that was specified by the matching mapping. What the PowerShell script does is completely up to you. TFS Deployer will provide a global variable to the PowerShell script named $TfsDeployerBuildDetail which has many of the same properties as the Microsoft.TeamFoundation.Build.Client.IBuildDetail interface, such as the DropLocation. To see some of the other variables TFS Deployer provides to the PowerShell scripts, include the following command in a deployment script: Get-ChildItem Variable:TfsDeployer*

Here is an example script to deploy website files from the drop location to the local machine:
$Destination = "C:\Program Files\Foo\Web\"
New-Item -ItemType Directory -Path $Destination -Force
Get-ChildItem -Path $Destination | Remove-Item -Recurse -Force
$Source = Join-Path -Path $TfsDeployerBuildDetail.DropLocation -ChildPath PublishedWebsites\FooWeb
Get-ChildItem -Path $Source | Copy-Item -Destination $Destination -Recurse -Force

Last edited Jul 6, 2010 at 12:01 PM by jstangroome, version 15

Comments

mbauer23 May 22, 2012 at 6:24 PM 
Hi . is there any plans to complete to information on how to use TFSDeployer. The information thus far has been very helpful.