November 2012

Volume 27 Number 11

Team Foundation Service - Implementing Build Automation with Team Foundation Service Preview

By Tim Star | November 2012

In this article you’ll find out how to implement build automation with Team Foundation Service Preview (TFS Preview). As Visual Studio ALM Rangers, we’ve been using TFS Preview to run builds entirely in the cloud since March. Although support is in place for all of the Team Build features—including gated check-ins and custom build definitions—our focus in this article is not on the basic build capabilities of TFS Preview. Rather, we’ll show how to set up build automation on-premises for scenarios where the development team needs more control over the configuration of the build machine than is available on Azure.

For detailed information about how to execute a build on TFS Preview, see Aaron Bjork’s “Visual Studio ALM + Team Foundation Server Blog” at bit.ly/H9epDn.

To recap, the Rangers are a group of experts who promote collaboration between the Visual Studio product group, Microsoft Services and the Microsoft Most Valuable Professional (MVP) community by addressing missing functionality, removing adoption blockers, and publishing best practices and guidance based on real-world experience.

Connecting TFS Preview to Team Foundation Build Service

To automate builds of your software projects, you use Team Foundation Build Service to create a build machine that runs either on-premises or in a hosted scenario. Once your build machine is set up, you need to create a build definition in Visual Studio with instructions about which code projects to compile and how to configure many other options. You must first choose your deployment scenario for Team Foundation Build Service and set up your build machine appropriately.

Preparing for the Installation Before you can install Team Foundation Build Service on a machine connected to TFS Preview, you need to perform the following tasks:

• Make sure to use the Team Foundation Build Service available with Team Foundation Server 2012. The Team Foundation Server 2010 build agent and controller are not compatible with Team Foundation Service on Azure Preview. You must use the build server software that’s part of Team Foundation Server 2012.
• Subscribe to TFS Preview.
• Identify the URL to your Project Collection on TFS Preview.
• Configure your user credentials to have “Edit collection-level infor­mation” permissions, which are included in the default permissions for the Project Collection Build Administrators groups.
• Configure your firewall to allow inbound connections on TCP port 9191 on the hosted virtual machine (VM) firewall so TFS Preview can communicate with the build service. To ensure the security and integrity of your build machine, always keep Windows Firewall turned on.

Installing, Configuring and Executing The process of deploying Team Foundation Build Service on a hosted physical machine or a VM tied to TFS Preview is almost identical to that of deploying an on-premises Team Foundation Server, as described in the MSDN Library article, “How to: Install Team Foundation Build Service,” at bit.ly/Oazdwd and the ALM Rangers “Installing Build for Team Foundation Service” guide at go.microsoft.com/fwlink/?LinkID=251576.

The main difference is how you secure the build drop. Although you can create a build drop shared folder on the hosted physical machine or the VM, you shouldn’t expose the shared folder directly to the Internet. You don’t want to increase the attack surface of the build server. As illustrated in Figure 1, using the Secure FTP feature of IIS and publishing the build drop folder is probably the best method for making your builds securely available over the Internet.

Figure 1 Secured Build Drop Access

Dealing with Performance, Bandwidth and Download Concerns Build automation is generally an I/O-intensive operation. When you consider that most builds will download the complete source code of a solution, available bandwidth and download caps are an important factor. To reduce the number of files downloaded during each build, you should consider setting up Team Foundation Server Proxy. The proxy enhances network throughput by caching copies of source control files in a remote location. By caching copies on-premises, the proxy helps the build process avoid a costly download of the files. Caching copies on-premises definitely reduces bandwidth consumption, which will affect the download caps imposed by your Internet Service Provider, as well as improve the overall performance of the build process.

Configuring On-Premises Build Servers

To deploy an on-premises build server that leverages TFS Preview in the cloud, we need to borrow some concepts and industry practices from Web hosting. In most corporate Web hosting environments, a perimeter network (also known as a demilitarized zone—or DMZ—or as a screened subnet) is used to create a secured network or enclave. The perimeter network separates servers that are exposed to the Internet from the corporate network.

A perimeter network can be implemented in a couple of ways. Traditionally, it’s implemented by using two physically separate firewalls, each restricting the traffic flow to and from the networks, as illustrated in Figure 2.

Figure 2 A Perimeter Network with Two Separate Firewalls

A more modern approach to implementing a perimeter network uses a secured Virtual Local Area Network (VLAN) and relies on a single firewall that controls all network traffic, as shown in Figure 3.

Figure 3 A Perimeter Network with Virtual Local Area Networks

Firewall Configuration for TFS Preview and Team Foundation Build Service Communication

Because of the numerous variations in firewall configuration among the various manufacturers, we’re going to limit our discussion to the conceptual level. In this context, two aspects of firewall configuration are important: publishing and access rules.

Publishing refers to the act of opening TCP and User Datagram Protocol (UDP) ports on the external-facing interface or wide area network of the firewall to make services such as Web access, e-mail and Virtual Private Networking available on the Internet. To maintain a secured build server, you need to define publishing in your firewall in the following way:

• Interface: External
• Port Number: 9191
• TCP/UDP: TCP
• Scope: All networks (Internet)

Notice that the scope is set to “All networks (Internet).” You might want to consider limiting the scope of the publishing to the IP set of TFS Preview to prevent other clients or hosts on the Internet from accessing this machine. Adding traffic restrictions adds a second layer of security. You can obtain the latest IPs of TFS Preview by doing a DNS name server lookup. Keep in mind that IPs can change at any time. Some firewalls have the ability to do a reverse lookup against a host’s fully qualified domain name to help you monitor current IPs.

Access rules are the constraints imposed on network traffic between the internal and external interfaces of a firewall. To maintain a secured build server, you need to define the access rules in your firewall as shown in Figure 4.

Figure 4 Defining Access Rules

Detecting Intrusions As with any Web hosting infrastructure, you need to consider implementing intrusion detection when you publish a Team Foundation Build Service server to the Internet.

Securing TFS Preview and Team Foundation Build Service CommunicationYou can strengthen the security of your on-premises build server deployment connected to TFS Preview by configuring the services it uses. We recommend that you configure your deployment to require HTTPS with SSL to maximize the security of your deployment.

To configure the services to use HTTPS with SSL, you need the following:

• An SSL certificate issued by a commercial certificate authority (CA).
• A registered Internet domain name.
• A DNS host name record or alias (CNAME) resolving to the external IP (Internet-facing) of the build server using your registered domain name. (To procure an SSL certificate from a commercial CA, you need a registered domain name.)
• Local Administrator privileges on the build server.
• An internal IP address mapped to the external IP address for the build server on your firewall.

After you’ve met these requirements, you need to open TCP Port 9191 on your firewall and forward it to the internal IP address of your build server and then configure Team Foundation Build Service to use SSL.

Instructions on how to configure SSL for Team Foundation Server 2010 Build Service are available in the MSDN Library subtopic, “Installing the Certificate on Build Servers,” at bit.ly/OA10Vz.

Setting Up Authentication To run the Build Service Configuration Wizard and add a Team Foundation Build Service instance to TFS Preview, you need two user accounts:

• Windows Live ID mapped to a Project Collection on a TFS Preview account (subscription)
• Local or domain user account to use as a service account on the build server

During the initial configuration phase, the Build Service Configuration Wizard uses the Windows Live ID to gain access to TFS Preview and establish a mapping between the Project Collection and the build server. Subsequently, you need to provide the service account credentials for either a domain or a local user account. Using a domain user account as a service account is the best security option. Domain user accounts offer a simpler approach when using a folder share on another server.

Monitoring Builds You can monitor your builds through the Build Notifications power tool that’s part of the Team Foundation Server 2010 Power Tools (December 2011) release. Figure 5 shows the Build Notifications Options dialog box. If you’re working with Visual Studio 2012, you need to install Team Explorer 2010 SP1 and the GDR compatibility update before you install Team Foundation Server 2010 Power Tools. You don’t need to worry about version conflicts because side-by-side installation of Visual Studio 2012 and Visual Studio 2010 is supported.

Figure 5 Monitoring Build Status

Configuring Team Build Definitions with the Hosted Build Controller

TFS Preview provides a pool of build machines that can compile, test and package your application.

Configuring a Hosted Build Controller To use a hosted build controller, the only configuration necessary is that your build definition must specify the hosted build controller in the Build Defaults tab, as shown in Figure 6.

Figure 6 Selecting a Hosted Build Controller

Dealing with Constraints With TFS Preview, you don’t have complete control over the build machine, which means that if you have an external dependency in your project, you need to either check it in or enable it to be downloaded from a public NuGet feed.

The Visual Studio 2012 and Visual Studio 2010 SP1 (which requires the GDR compatibility update) development environments are installed on the TFS Preview build image, meaning that only projects created with these versions of Visual Studio are supported.

If you want to build Windows Store apps, you need to install the build service on Windows 8. For more information on using Team Foundation Build to build and test a Windows Store app, go to bit.ly/T3tFSt.

Unit Testing TFS Preview supports unit testing as a part of the build. Unit tests using MSTest work without additional configuration. To execute tests using other unit-testing frameworks, such as NUnit or xUnit, you need to verify that the corresponding test adapter assemblies are checked into source control and then set the build controller’s “Version Control Path to Custom Assemblies” property to this location.

Identifying Complex Build Scenarios Deciding which build configuration is best for you depends on the complexity of your build. For straightforward build scenarios with no automated deployment, the build service hosted in TFS Preview is sufficient. For build processes that are more complex, you should use an on-premises build configuration. A complex build configuration would include any build template that meets at least one of these criteria:

• Has automated deployment activities in your workflow
• Contains solutions that were created in versions of Visual Studio earlier than Visual Studio 2010 SP1
• Calls Visual Studio Lab Management
• Interacts with an on-premises machine
• Requires a testing framework without a Visual Studio test adapter

Solutions that require third-party assemblies can be built on TFS Preview as long as you check those assemblies into version control or enable your solution to download them from a public NuGet feed.

Automated Testing and Lab Management Even though TFS Preview doesn’t currently support Visual Studio Lab Management, you can still create and run several types of automated tests with Visual Studio. Here are some examples:

• Unit tests
• Coded UI tests
• Web performance tests
• Load tests
• Generic tests

You can run these tests after a build has completed to evaluate its quality. These tests are often called build verification tests (BVTs) or smoke tests. They typically consist of a broad suite of tests that are used to verify key areas of an application in a particular build. A build is considered a success if all the tests in the BVT pass.

The online MSDN Library article, “How to: Configure and Run Scheduled Tests After Building Your Application,” at bit.ly/P2EKB7 describes all the procedures that are required to create and run BVTs.

Doing Coded UI Testing in a Team Build You can use a coded UI test to spice up your BVTs. A coded UI test starts an application as part of the test execution. You must make sure to configure the service account for the build service that’s used to start the application. This service account has to be the same as the user account of the active user on this computer. If the service account and the user account aren’t the same, the application won’t start. You also need to ensure that the Build Service Host property Run the Build Service As is set to Interactive Process in the Team Foundation Server Administration Console/Team Foundation Build Configuration.

Looking Ahead

In future articles, we’ll provide guidance on how to set up and configure TFS Preview to enable collaboration for enterprise development shops that want to leverage the services of remote development shops as part of an outsourcing model. For more information on the ALM Rangers, see bit.ly/HrYqAl.

Mario Contreras is a Toronto-based senior consultant with Microsoft Consulting Services, an ALM coach and a frequent speaker at technical conferences. During his tenure at Microsoft Canada, he has led some of the largest Team Foundation Server implementations. Contreras is an active member of the Visual Studio ALM Rangers team.

Tim Omta is a senior application development manager in Phoenix. He has worked for Microsoft as both a product developer and a test developer and is currently a field consultant through Microsoft Premier Support for Developers. Omta is an active member of the ALM Rangers.

Tim Star is a principal consultant with Intertech Inc., focusing on training, consulting and Visual Studio ALM. He is an MCPD, MCTS, MCT, Visual Studio ALM External Ranger and three-time MVP award recipient. He spends his time writing code, teaching and delivering ALM guidance.

Thanks to the following technical experts for reviewing this article: Jim Lamb, Mario Rodriguez, Willy-Peter Schaub and Patricia Wagner