Now that a preview of the Team Foundation Service is available, let’s start talking about how to take your Application Lifecycle Management (ALM) to the cloud with it. While the service doesn’t currently offer everything that the typical server installation does (e.g. Lab Management, SharePoint Integration and Reporting [SSRS]) it does pack a lot into a “Preview.”
The area I’m concerned with (at the moment) is the build integration and how to setup and configure the controllers/agents. In order to follow along you’ll have to be using a virtual machine of the latest bits (i.e. Visual Studio Team Foundation Server 11) and an already configured tfspreview account. Now without further ado, let’s get started.
Configuration of the build service is straight forward and the wizard makes this an extremely easy process. There are however a few noteworthy items that should be mentioned.
Make sure that the account you choose to run the service has the correct permissions especially if you’re going to use a drop folder on another server. While I’m using a local Administrator account, best practice is to use a least privileged domain account with the appropriate permissions set.
You might receive the following “Build Service Verification” error on the review screen:
“TF400071: The provisioned service account for this collection could not be retrieved. This likely means that you do not have the correct permissions.”
As you can see, I received this error and the cause could be a number of things, namely the Windows Live ID that is used at the outset of the wizard doesn’t have the proper permissions set. Specifically the permissions assigned to it via the TFS site console. You can check this by logging into Team Web Access, clicking “Administration -> Default Collection -> Members.” Locate the particular Live ID account and then click “manage membership” under the “GROUP MEMBERSHIP” item to the right. That will list all of the groups that this Live ID login belongs to. Verify that this Live ID is in the “Project Collection Administrators” group.
If the Live ID is not in this group then go ahead and add it. Once the permissions have been verified but you’re still receiving this error it may be due to a connectivity issue (i.e. timeout) as evidenced by this log entry:
Inner Exception Details:
Exception Message: The operation has timed out (type WebException)
Exception Stack Trace: at System.Net.HttpWebRequest.GetResponse()
At this point, go ahead and re-rerun the verification tests. After completing the wizard launch the TFS Administration Console and confirm that the service, controller and agent are running:
Now that you have the build configuration is set, let’s create a new build definition. This is going to be done via Visual Studio as currently you cannot do this from the site. If you’re not sure how to create a build definition you can refer to the MSDN documentation. Once a build definition has been saved you can queue this build definition by using either Team Explorer or through the site. You can see that while both dialogs are slightly different both display the same information.
After a build definition has been queued, hopefully it will build successfully. Unfortunately I broke the build [gasp!] as I didn’t have a correct namespace but the subsequent build completed. This would be a perfect segue for advocating the use of gated check-in’s but I won’t digress. Notice that the “Build Quality” has been updated and that there’s a lock icon for the completed build which means that build will be retained indefinitely. Same functionality as the standalone version but the key take away here is that it’s available via the web.
I’m sure in the not so distant future that the lack of the aforementioned features and capabilities will be included as well as an automated build service. Once that parity occurs, the line between the server and service will forever be blurred.
Thanks to Trevor Hancock (Senior Support Escalation Engineer here at Microsoft), there’s a great forum post of “known issues” with regards to this service preview.