Rik recently posted about the work we have done to automatically provision TFS build agent VMs. This has come out of us having about 10 build agents on our TFS server all doing different jobs, with different SDKs etc. When we needed to increase capacity for a given build type we had a problems, could another agent run the build? what exactly was on the agent anyway? An audit of the boxes made for horrible reading, there were very inconsistent.

So Rik automated the provision of new VMs and I looked at providing a PowerShell script to install the base tools we needed  on our build agents, knowing this list is going to change a good deal over time. After some thought, for our first attempt we picked

  • TFS itself (to provide the 2013.2 agent)
  • Visual Studio 2013.2 – you know you always end up installing it in the end to get SSDT, SDK and MSBuild targets etc.
  • WIX 3.8
  • Azure SDK 2.3 for Visual Studio 2013.2 – Virtually all our current projects need this. This is actually why we have had capacity issue on the old build agents as this was only installed on one.

Given this basic set of tools we can build probably 70-80% of our solutions. If we use this as the base for all build boxes we can then add extra tools if required manually, but we expect we will just end up adding to the list of items installed on all our build boxes, assuming the cost of installing the extra tools/SDKs is not too high. Also we will try to auto deploy tools as part of our build templates where possible, again reducing what needs to be placed on any given build agent.

Now the script I ended up with is a bit rough and ready but it does the job. I think in the future a move to DSC might help in this process, but I did not have time to write the custom resources now. I am assuming this script is going to be a constant work in progress as it is modified for new releases and tools.  I did make the effort to make all the steps check to see if they needed to be done, thus allowing the re-running of the script to ‘repair’ the build agent. All the writing to the event log is to make life easier for Rik when working out what is going on with the script, especially useful due to the installs from ISOs being a bit slow to run.



\# make sure we have a working event logger with a suitable source  
Create-EventLogSource -logname "Setup" -source "Create-TfsBuild"  
write-eventlog -logname Setup -source Create-TfsBuild -eventID 6 -entrytype Information -message "Create-Tfsbuild started" 

 

\# add build service as local admin, not essential but make life easier for some projects  
Add-LocalAdmin -domain "ourdomain" -user "Tfsbuilder"

  
  
  
  
\# Install TFS, by mounting the ISO over the network and running the installer

\# The command ‘& $isodrive + ":tfs\_server.exe" /quiet’ is run

\# In the function use a while loop to see when the tfconfig.exe file appears and assume the installer is done – dirty but works

\# allow me to use write-progress to give some indication the install is done.  
Write-Output "Installing TFS server"  
Add-Tfs "\\storeISO ImagesVisual Studio20132013.2en\_visual\_studio\_team\_foundation\_server\_2013\_with\_update\_2\_x86\_x64\_dvd\_4092433.iso"

 

Write-Output "Configuring TFS Build"  
\# clear out any old config – I found this helped avoid error when re-running script

\# A System.Diagnostics.ProcessStartInfo object is used to run the tfsconfig command with the argument "setup /uninstall:All"

\# ProcessStartInfo is used so we can capture the error output and log it to the event log if required  
Unconfigure-Tfs

  
\# and reconfigure, again using tfsconfig, this time with the argument "unattend /configure  /unattendfile:config.ini", where

\# the config.ini has been created with tfsconfig unattend /create flag (check MSDN for the details)  
Configure-Tfs "\\storeApplicationInstallersTFSBuildconfigsbuild.ini"

 

\# install vs2013, again by mounting the ISO running the installer, with a loop to check for a file appearing  
Write-Output "Installing Visual Studio"  
Add-VisualStudio "\\storeISO ImagesVisual Studio20132013.2en\_visual\_studio\_premium\_2013\_with\_update\_2\_x86\_dvd\_4238022.iso"

 

\# install wix by running the exe with the –q options via ProcessStartInfo again.  
Write-Output "Installing Wix"  
Add-Wix "\\storeApplicationInstallerswixwix38.exe"

 

\# install azure SDK using the Web Platform Installer, checking if the Web PI is present first and installing it if needed

\# The Web PI installer lets you ask to reinstall a package,  if it is it just ignores the request, so you don’t need to check if Azure is already installed  
Write-Output "Installing Azure SDK"  
Add-WebPIPackage "VWDOrVs2013AzurePack"

 

write-eventlog -logname Setup -source Create-TfsBuild -eventID 7 -entrytype Information -message "Create-Tfsbuild ended"  
Write-Output "End of script"

So for a first pass this seems to work, I now need to make sure all our build can use this cut down build agent, if they can’t do I need to modify the build template? or do I need to add more tools to our standard install? or decide if it is going to need a special agent definition?

Once this is all done the hope is that when all the TFS build agents need patching for TFS 2013.x we will just redeploy new VMs or run a modified script to silently do the update. We shall see if this delivers on that promise