In Team Foundation Server 2010, you know have the ability to (easily) have multiple build agents on the same build server. You were able to do this in TFS 2008 but it really wasn’t supported. However, this raises an interesting challenge: some processes and executables aren’t designed to handle being run simultaneously in multiple contexts on the same build machine. Some applications can’t or have a difficult time handling concurrent access from multiple build servers at the same time as well.
I’ve listed a few of the scenarios that I can I remember off the top of my head:
- Automated UI Testing – running automated UI tests from two different builds on the same build machine can lead into utter confusion! :) Mouse clicks going everywhere! Let’s just stick to one set of automated UI tests running on an individual machine at the same time.
- Running Automated Tests that Collect Code Coverage Information - This was an interesting limitation that I found in the 2008 release. It seems that the code coverage data collector did not support collecting from more than one automated testing run happening concurrently on the same machine. (This might actually have been addressed in the 2010 release but I’m not quite sure.)
- Dotfuscator – As far as I remember, this was another tool I remember having concurrency issues on the same build machine.
- Symbol Server Store Access – This is something new to me and I’m not intimately familiar with all of the details behind this limitation. It looks like you can not use the symbol server publishing tools against the same symbol server storage location at the same time even on multiple machines. (See example below.)
- Other Tools – I’m sure there are other build processes and tools we use that have limitations. I’m sure many will be found out now that concurrent usage is more easily possible now. Leave a comment below if you find any other examples and I’ll add them to this list.
Thankfully, the Team Build folks have provided us the ability to handle those specific scenarios where concurrent access isn’t supported as part of the build process. That’s through the use of the Shared Resource Scope activity. (Microsoft.TeamFoundation.Build.Workflow.Activities.SharedResourceScope)
Basically what it does is define a region of the build process that will only be allowed to be entered by one build across the entire Team Project Collection (even multiple build machines/agents) that share a matching resource name string. It’s very similar to how we use the lock statement in C# or creating mutex objects. (You might have to dust off those old computer science books from school.)
However, if you only want to limit the scope to a particular build server (instead of the entire Team Project Collection) then you can just put the build server machine name into the resource name string. Don’t hardcode the machine name though and instead use one of the properties that are provided for you (in case the build doesn’t run on the same build machine every run because of the new agent pooling feature.) Instead you could use an approach like this for the resource name expression:
=String.Format(“{0}_{1}”, BuildAgent.BuildServer, “AutomatedUITesting”)
Example in the Default Build Process Template in TFS 2010
Interestingly, there is an example usage of this activity and pattern available for us to look at in the default build process template file that’s available out of the box. It’s usually located in version control here: $/TeamProjectName/BuildProcessTemplates/DefaultTemplate.xaml. Lower down in the default process, there is a section that attempt to publish the symbols to a symbol server storage location if you have specified it in your build definition properties. My Assumption: However, since only one build server can be publishing to a particular location at the same time, then a controlled scoped region is created based on the location property. (SourceAndSymbolServerSettings.SymbolStorePath)
That way you don’t have to worry about any build agent inside a Team Project Collection ever publishing to the same symbol server location at the same time.
Recently added: It looks like this particular issue has already been discussed and that my assumption above is correct. Adam blogs about it here. Check it out. How about that?
One more thing to note about symbol server publishing is the use of the SharedResourceScope activity in the build process template. The purpose is to make sure that concurrent instances of symstore.exe aren’t adding symbols at the same time, as the tool doesn’t support concurrent access to a symbol server share. SharedResourceScope uses the Team Foundation Server to control access to an arbitrarily named resource, in this case the share. That way, if multiple builds are trying to publish symbols at the same time, the requests are queued and only one will publish at a time, while the others wait (instead of fail due to file access errors or “step on each others’ toes”). PublishSymbols does not care about shared resource locks, but it is contained within the SharedResourceScope, so won’t be executed until the lock is appropriately acquired.
Other Properties Available for SharedResourceScope Activity
As you can see above there are a few other properties available for you to configure for this activity:
- MaxExecutionTime: This is a TimeSpan that can be specified to limit the amount of time that a particular agent has control of the scope. This is particularly useful for a resource scope that is going to be heavily used and can help you prevent a rogue build from eating up that resource indefinitely. If the process inside the scope can’t complete before this time period has expired then an exception gets thrown.
- MaxWaitTime: This is a TimeSpan that can be specified to limit the amount of time to wait for control of the scope. The example above limits the amount of waiting to one hour and if it doesn’t reserve the scope within that time period an exception gets thrown.
Thanks to Aaron Hallberg for all of the background information and existence of this activity!
Ed Blankenship