Xcode, TFS and the ALM …
Many organizations have been faced with centralizing all of their ALM tools in order to enable better integration across all the tools for each role in your app lifecycle. Team Foundation Server (TFS) provides an excelllent integration environment for Microsoft .NET projects and even application developed in Eclipse (Java, Android, etc.). There have been many recent advances into the mobile space especially in iOS applications and my work is certainly no exclusion to this. Since CEI has adopted TFS as our ALM platform I have been keeping all of my Xcode projects in TFS via the Subversion bridge.
But what about builds?
While storing Xcode projects in TFS works quite well (including the ability to associate with Work Items) one of the primary features of TFS (and any integrated ALM platform) is Build Automation. Since Xcode projects can ONLY be built on Mac OS X there simply was no way to trigger a build using Team Build in TFS. Alternatives exists, for sure … there are other CI platforms that can be triggered via SVN (svnbridge in TFS) but that requires more investment in software.
What I wanted was a solution leveraging Team Build as much as possible and a Mac only where it was needed to compile the Xcode project. The thought of implemeting a Team Build Agent on the Mac was …. frightening 😉 So, instead, I decided to automate copying the source code from the Team Build server to the Mac (using SCP), remotely triggering xcodebuild (via SSH), and finally retrieving the results (again, via SCP). It turns out this was pretty straight-forward and reliable. To share this, I created a Codeplex project to host the source code and binaries.
TFS Xcode Build v1.0
Check out the project hosted on Codeplex here: http://tfsxcodebuild.codeplex.com/. There you can find the latest source code, binary release and documentation.
While setting up and configuring TFS for a client, the other day, we ran into a strange error during configuration. The TFS 2010 configuration failed to complete because the TfsJobAgent service could not start. The error was simple and straight-forward: Access Denied.
Usually there are several items to check here:
- Are the credentials for the service account correct? (The error would have told us Logon Failure anyway)
- Does the service account have the Log on as service policy right?
- Is the service account NOT in the Deny log on as service policy?
- Are these policies being locked/overridden via an AD policy, etc.?
Well … we exhausted all of these options and still could not determine the cause. We decided to get a fresh set of eye in on the issue and he pointed out the brutally obvious to us by asking: Does the service account have file system rights to the EXE? Check the ACLs.
Brilliant! Turns out this client restricts folder ACLs on their servers to aid in security and the TFS service account didn’t have access to this folder.
So now I can add this to my “pre-flight” checklist.
Per Brian Harry:
Mike Fourie just published a bunch of workflow activities/actions for TFS builds. It’s a great set of extensions that makes TFS builds even more powerful with less work.
While there doesn’t seem to be any true documentation on the actual extensions themselves, looking at the bundled/generated CHM it looks like we have some new extensions in the following categories:
- IIS7 Integration – looks like creating components in IIS to roll-out a web application (application, site, app pool, etc.)
- VB6 Builds
- Hyper-V/VirtualPC Integration – Tools to manage Virtual PCs and to interact with Hyper-V
- SQL Server command execution
- WMI script execution
- PowerShell script execution
- ZIP Integration (one that is frequently asked of me from our customers)
- Sending emails
- Code Metrics integration
- StyleCop integration
- NUnit integration
- File system, assembly info/update, RoboCopy and more
Seems like a pretty decent list of enhancements for free! Grab them here: