I use Team Build to automate the build and deployment of my projects. In the build project, there are settings that allow us to configure the build directory and drop location of the files. The build directory is a path in the build machine, and this does not really change. The drop location is a path where you want the files to be copied after a successful build. Depending on your development environment, you may want these files to be copied to different servers. For example, there may be a development, staging and production location. For our process, we keep a copy of the build in the drop location, and from this location , we copy to the other servers. This allows us to recover previous builds.
Team Build uses MSBuild to perform the build process. MSBuild allows us to pass input parameters which can be used to run a conditional statement and determine the drop location dynamically. When I queue a new build, I add a parameter in the MSBuild command-line arguments (See Queue New Build under TFS Explorer). This parameter has this format:
/p:DeployTo=develop (/p = command switch)
The parameter name and value is just a key/value pair which you can reference in the build script much like you would use parameters in a XSLT file. The /p is a MSBuild command switch that denotes properties. The TFS build project file is actually a XSLT file, so we can leverage the use of the Choose conditional statement to determine where to copy the files.
<Choose>
<When Condition=" '$(DeployTo)'=='stage' ">
<PropertyGroup>
<DeployPath>\\stageServer\drop</DeployPath>
</PropertyGroup>
</When>
<When Condition=" '$(DeployTo)'=='production' ">
<PropertyGroup>
<DeployPath>\\prodServer\drop</DeployPath>
</PropertyGroup>
</When>
<Otherwise>
<PropertyGroup>
<DeployPath>\\devServer\drop</DeployPath>
</PropertyGroup>
</Otherwise>
</Choose>
This script basically checks the value of the parameter DeployTo and creates a variable named DeployPath. If no parameter is provided, it defaults to the development environment. You can also add additional variables which you can use to set other properties like build quality. Do make sure to replace the path with something relevant to your environment. We can now create a Target (group of tasks) and determine where to copy the files.
<Target Name="AfterDropBuild" >
<Message Text="Copying Files to: $(DeployPath)" ></Message>
<!--Define New Deployment Files To Be Copied USE **\* to get all subfolders-->
<ItemGroup>
<Content Include="$(DropLocation)\$(BuildNumber)\Release\myproduct\**\*"
</ItemGroup>
<!--Task: Copy all the files and subfolders to the path defined by DeployPath-->
<Copy SourceFiles="@(Content)" DestinationFolder="$(DeployPath)\%(RecursiveDir)" ContinueOnError="false"></Copy>
</Target>
We can now check-in the project file and queue a new build. After the build is successful, we can take a look at the folders in the other server and validate that the files were copied successfully. If the files are not in the new location, take a look at the build log (drop location folder) and look for the"Copying Files To:" message that we added in the new target. The message should displayed the path that was selected. This is an approach to troubleshoot and see what is taking place with the build script.
Thanks for reading.