Visual Studio Application Lifecycle Management (ALM) allows you to manage lifecycle of the project, provides ways to manage issues and overall improves productivity. Along with various features like workitem tracking, version control and project management; Server side build is an integral part of Team Foundation Server. Using Team Build, you can create and manage build processes and use the build process to automatically test the application. You can trigger the build every time check-in is done. This is part of Continuous Integration (CI). Build can be even setup as a quality gate and only allow those check-ins to be successful if the code doesn’t break the server side build. This feature is called as Gated Check-in.
In Team Foundation Server 2013 Build, there are a lot of new features added and some old features enhanced. Today we will explore 3 of these features.
- Integration of Git team project
- Change in Build Default Template for usage of batch files or Powershell scripts in Build
- A new option for build output location
Integration of Git Team Project in Team Build
Team Foundation Server 2013 supports Git for version control. While creating a Team Project, we can set it to use Git repository for version control.
Once the project code is ready, committed to local Git repository and pushed into Team Project’s Git repository; we can create a Build Definition within that Team Project. To do so, select a New Build Definition option from Build as usual. We can now provide the Queue processing for the Build as Enabled, Paused or Disabled. Once the name of the Build Definition is specified and trigger selected, we can specify that the source will be selected from Git repository.
Here we can specify the Git repository name, the branch to use and if required, which branch to monitor for CI (Continuous Integration).
A separate Default Template for Git is provided
Overall Build process looks similar to the usual build process except the part which pulls the code to be built from the Git repository
Powershell scripts in Build
The second new feature that we will explore today is using batch files or Powershell scripts as part of the Build 2013. The build default process template provided with Team Foundation Server 2013 is TfvcTemplate.12.xaml
There are some differences in this process template in comparison to previous version of Team Foundation Server. In the following diagram, the templates are shown next to each other, with the TFS 2013 template shown to the right
Observe the changes in the two templates. There are some additional activities like running scripts before and after the compilation as well as before and after tests are executed. Run MSBuild is responsible for compiling on various platforms and configurations.
Publish Symbols is used to publish symbol data and the path where to publish these symbols.
We will focus on one important addition and that is to execute scripts or batch files. From the diagram below you can see how the parameters and path can be specified.
Pre-build script arguments and path are used to execute script before compilation. Post-build script arguments and path are used to execute script after compilation. These scripts can be put in the source control on Team Foundation Server.
Similar arguments and path are available for before the execution of test related assemblies and after the tests are executed.
Overall this has given a more flexible way of customizing process template. Instead of workflow customization, we can provide scripts for pre and post standard activities of compilation and testing. You can perform various tasks which need to be executed before the compilation and after the compilation, like providing version number for the assemblies.
Passing environment parameters to the script or to MSBuild
There are a number of TF_BUILD environment related variables which can be required to provide some process logic. I am noting some of them here
TF_BUILD: makes part of the script conditional
TF_BUILD_BINARIESDIRECTORY: the folder from where the build process copies files to staging location.
This folder is automatically created unless you have specified Output Location as AsConfigured mentioned as the third new feature in the beginning of this article.
SingleFolder: default setting, all binaries will be dropped at a single location
PerProject: every project or solution will have its own output location.
AsConfigured: a script can be used to copy binaries at a particular location.
TF_BUILD_BUILDDEFINITIONNAME, TF_BUILD_BUILDDIRECTORY, TF_BUILD_BUILDNUMBER, TF_BUILD_BUILDREASON, TF_BUILD_BUILDURI, TF_BUILD_DROPLOCATION, TF_BUILD_SOURCEGETVERSION, TF_BUILD_SOURCESDIRECTORY and TF_BUILD_TESTRESULTSDIRECTORY are remaining environment parameters. I would encourage you to explore them.
We can get these variables by using the process template. We can use the GetEnvironmentVariable as the component from toolbox and configure it in xaml. The
Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables.BuildDefinitionName will provide the build definition name.
Observe the various values available
If we have set the output location as AsConfigured the variable data can be passed to MSBuild using MSBuild arguments
The environment data can be passed using the scripts as mentioned earlier.
In this article, we discussed 3 new features available with Team Foundation Server 2013. We discussed how Git repository can be incorporated in Team Build. We also discussed how to customize the build without changing the process template. We can use the environment variables either by passing to MSBuild or scripts. A separate location for dropping binaries can be configured with Output Location.