You've probably noticed that Team Foundation Server 2015 introduces a new automated build system.  One of the great things about this new system is that it's based on PowerShell.  At this point, you're probably thinking "Ok.  PowerShell.  Fantastic.  Why do I care?"  Well, that PowerShell-centric approach allows you to much more easily customize your builds.  Need to do some logic?  Stuff it in a PowerShell script, call that *.ps1 script from the build and you're off.

When you start customizing your TFS Builds using PowerShell (ps1) scripts, you'll pretty quickly notice that these PowerShell scripts integrate with the TFS Build system through environment variables.  When a build runs on a TFS build agent, a whole bunch of environment variables get set and those variables have all the information about that build.  For example, if you need to reference something that's been retrieved from source control, you'll need to access the 'BUILD_SOURCESDIRECTORY' environment variable in order to look up the path on the local disk where all your source code got downloaded.

There are a lot of environment variables that get set for each build and it's initially tough to learn what they all are.  On my last build, I counted 51 separate environment variables that get set.

How do you learn what's available?

So how do you discover and learn what all the values are that you can use?  My #1 recommendation is to create a simple build and call a PowerShell script that exports all the values for all the available environment variables.

Here's a simple script that I wrote that does that:

[CmdletBinding()]

param()

$environmentVars = get-childitem -path env:*

foreach($var in $environmentVars)
{
 $keyname = $var.Key
 $keyvalue = $var.Value
 
 Write-Output "${keyname}: $keyvalue"
}

In order to reference that script from an automated build, you'll need to add it to source control.  I usually create a folder off the root of my source repository called "BuildScripts" and add my custom scripts into that directory like what I did in the image below.  

[caption id="attachment_6811" align="alignnone" width="470"]
[/caption]

Once you've added that PowerShell script to version control, you can edit your build definition to call the script.  First you'll click "Add build step..." and add a PowerShell script step.  When that's been added, you need to populate the "Script filename" value.  You can do this by clicking the "..." button and choosing your PowerShell script in source control.  Save the build and you're done.

When you run your build, you'll eventually see a message saying something like "Starting task: Powershell: BuildScripts/export-environment-variables.ps1" followed by a bunch of environment variable keys and values.

The Environment Variables

The environment variables that get exported are going to be all of the values that are available and NOT just the values that get handed in by TFS Build.  Here are the values that got set by TFS on my build server.

As you can see, there are a whole lot of values that get set.  Hopefully, this gets you going on learning what they are and gets your going towards customizing your TFS2015 builds.

-Ben

-- Looking for help adopting the new Team Foundation Server 2015 build system?  Need help customizing?  Want some help deploying your applications from your TFS automated builds?  We can help.  Drop us a line at info@benday.com.