Follow us on Twitter
Follow us in Facebook
Office Dev Content
SharePoint Dev Content
Welcome to Part 2 of our series on Continuous Integration for SharePoint 2010. This article will cover configuring your TFS environment.
This series of posts introduces many new techniques for automating builds, deploying builds, and incorporating tests as part of the build process. To build a project, the dependent assemblies must be on that machine. This makes it difficult to use the same build server for both SharePoint 2007 and SharePoint 2010 extensibility projects. To address this, you can utilize a central Team Foundation Server (TFS) server with a build server that is specific to your project’s needs. If you want to test your application in a controlled environment, TFS enables you to provide your own test controller and test agent to perform tests.
To illustrate these techniques, we'll configure a TFS environment with a central TFS server, a Test Controller and Agent, and a Team Build server.
The lab environment we are working with mimics environments that are commonly found within companies utilizing TFS. Companies typically have existing domain controllers, SQL servers, and SharePoint Servers installed on separate machines (either physical or virtual). Development is done on a stand-alone machine, and code is deployed to the SharePoint environment.
We often see that companies provide a decentralized TFS environment. A central TFS server and its supporting databases provide the application, database, and reporting capabilities, while individual project teams provide their own build and test servers. This configuration helps isolate dependencies that may be needed on a build server to successfully build the source. It also helps prevent multiple concurrent builds from depleting system resources by offloading the build process to separate servers.
The software installed on each machine:
SQL Server 2008 R2 Standard Edition
SharePoint Server 2010 Enterprise Edition
SQL Server 2008 R2 Developer Edition
Office 2010 Professional Plus
SharePoint Designer 2010
Visual Studio 2010 Ultimate
Team Foundation Server 2010
Visual Studio Build Agent 2010
Visual Studio Test Controller 2010
Visual Studio Test Agent 2010
This post focuses on configuring the TFS tier of the development environment, creating a TFS application server, and separate build and test agents. Start by creating a TFS server using the single-server topology documented in “Scenario: Installing Team Foundation Server on a Single-Server” (http://msdn.microsoft.com/en-us/library/dd631899.aspx).
Create a new server named “TFS” that is joined to the SharePoint.lab domain. The account used to install should be a member of the local Administrators group. By convention, we'll use an account named TFSSETUP.
In addition to the setup account, you need to configure additional accounts for the TFS environment. The accounts are detailed in the setup documentation, “Accounts Required for Installation of Team Foundation Components” (http://msdn.microsoft.com/en-us/library/dd578625.aspx). Per the instructions, set up the following domain accounts:
Service account for SQL Server services
Service account for Windows SharePoint Services 3.0
Service account for Team Foundation Server
Report reader account
Service account for TFS Build
Proxy service for TFS
The documentation indicates that you should grant additional permissions for the accounts. To do this, edit the local group policy (in the Windows Start menu, type “Edit group policy” to find the Control Panel applet).
In the Group Policy Editor, navigate to Local Computer Policy / Computer Configuration / Windows Settings / Security Settings / Local Policies / User Rights Assignment and assign the permissions as stated in the documentation. For example, the TFSSERVICE, TFSBUILD, and TFSPROXY accounts require Log on As a Service permissions:
The instructions in the TFS setup guide are very complete here. Add the Web Server (IIS) role to your server, and then add the ASP.NET, Windows Authentication, and IIS6 Management Compatibility services.
In the SQL setup dialog, choose “New features or add features to existing installation”. After SQL runs its rule checks, install the setup support files. Enter your product key, accept the license terms, and choose SQL Feature Installation. The features you need to install are:
· Database Engine Services
· Full-Text Search
· Analysis Services
· Reporting Services
· Client Tools Connectivity
· Management Tools – Complete
The installation window looks like the following:
Note: You aren't required to install the Management Tools, but doing so helps in troubleshooting. Additionally, you aren't required to install the client tools, but it's useful to have them installed in case you want to configure aliases or network connectivity.
Setup verifies the selections through its rules and then prompts you to create a default or a named instance. For this example, choose a default instance. TFS can be used with named instances, but they require manual configuration. By selecting a default instance, the TFS setup will do most of the configuration work for analysis services and reporting services for us.
Setup verifies disk space requirements and then prompts you for the credentials of the various services. For this example, we'll use the same account for all services, providing a domain account.
Additionally, change the startup type for the SQL Server Agent service to Automatic. This service is used by TFS for scheduled jobs such as processing analytics.
Next, setup asks for the authentication mode for database engine services and prompts for SQL Server administrators. Select Windows authentication mode and add users who will have administrative privileges to SQL Server. For this example, we'll use an account called TFSSETUP to install and administer TFS. Additionally, our DBA connects by using an account for administration called SQLADMIN.
The next step is Analysis Services configuration. Here, you are again prompted for users that will have administrative privileges to SQL, so provide the same users, TFSSETUP and SQLADMIN.
After configuring the Analysis Services, configure the Reporting Services by choosing the “Install the native mode configuration” option.
Finally, choose whether you want to send SQL Server error reports to Microsoft, then verify the configuration rules and click Install.
Open the Team Foundation Server Administration console. Click the Application Tier node, and then click the link to Configure Installed Features. Choose the “Standard Single Server” option and then click “Start Wizard”.
One of the benefits of using the wizard is that it will configure Analysis Services and Reporting Services for you. Provide a user account for SharePoint Products and SQL Reporting Services. The documentation suggests using a domain user account called WSSSERVICE.
Note: The Standard Configuration Wizard installs and configures Windows SharePoint Services 3.0. TFS can be configured to use SharePoint 2010 as its portal, but requires additional manual configuration steps. If you are following along with this post, it's important that the TFS server is on a separate machine from your SharePoint 2010 development machine.
Use the configuration wizard to verify all settings and then click Configure. If you receive a warning for SharePoint products, it is telling you that it will create a new application pool for the Default Web Site in IIS. Because this is a new installation, this warning can be safely ignored.
After you click Configure, the wizard will configure services on your machine.
Once the services are installed and configured, you can apply the latest updates. See Latest Updates Available for Team Foundation Server 2010 (http://social.msdn.microsoft.com/Forums/en/tfssetup/thread/79396175-af41-45d0-8e59-569af4bb2696). As of this writing, the latest update to TFS is Service Pack 1.
After the wizard completes, you'll see a summary of steps and a link to the configuration log.
After the installation completes, you need to add the TFS service account (we used TFSSERVICE as the account name) as a Content Manager role in SQL Reporting Services. Open IE as an Administrator and then navigate to http://tfs/Reports to access the Folder Settings.
Click Folder Settings to open it and then click New Role Assignment to add TFSSERVICE as a Content Manager.
The installation docs include this step as well, but we include it for completeness. Configure analysis services to restart on failure. To do this, open the Services Control Panel applet in Windows, right-click SQL Server Analysis Services, and then choose properties. On the Recovery tab, set each failure option to “Restart the Service”.
On the TFSBuild machine, install the Team Foundation Build Service. Do this by starting the TFS setup program and choosing to install only the Team Foundation Build Service on the machine.
Once the installation is complete, apply TFS Service Pack 1 to the machine.
Once Service Pack 1 is applied to the machine, configure the Build Service. Add the new TFS server as a connection.
After connecting to the TFS server, choose a project collection. For this example, we'll use the default collection that was created by the TFS installation.
The next step is to configure the build agent to run on our new build server.
Next, configure the user account. The default option uses NETWORK SERVICE, but it's recommended that you use domain accounts because it typically makes troubleshooting easier. Name the domain user account TFSBUILD.
Verify the settings and then click Configure.
On the TFSTest machine, install the TFS Test Controller. After installing, the dialog prompts you to install the Test Agent as well.
After installing Test Controller and Test Agent, open the Test Controller configuration tool. We'll cover its settings in depth in a future post, so for now, accept the defaults and apply the settings.
After configuring the test controller, configure the Test Agent using its configuration tool. We'll configure the Test Agent to run as an interactive process.
The next step is to register the test agent with a controller and specify the account that will run the test agent. For this example, create a user, TestUser1, to run the test agent. We'll show how to use the test agent with coded UI tests in a future article.
The Test Controller was configured in the previous section. It's running on the machine “TFSTest”, and defaults to run on port 6901.
After you provide the settings for the test agent, the wizard will perform configuration tasks.
The wizard tells us that we should add the account to the local administrators group. After adding the user to the local Administrators group, reboot the machine for the settings to take effect.
After rebooting, apply TFS Service Pack 1 to the TFSTest machine.
When you log into the machine using the TestUser1 account, you'll see Test Agent running as an interactive process.
Now that you’ve set up the environment, you need to verify the configuration. On the TFSBuild server, open the TFS Administration Console. On the Team Project Collections node, select Group Membership to add users as project collection administrators. For this example, we'll add the users CHRISOBRIEN and KIRKEVANS as administrators for the project collection.
Our development users (Kirk Evans and Chris O’Brien) are project collection administrators. As specified in the MSDN topic “Set Administrator Permissions for Team Project Collections” (http://msdn.microsoft.com/en-us/library/dd547204(VS.100).aspx), these users must be added to the site collection administrators group and the reporting services content managers group.
In the WSS 3.0 site created on the TFS server, add the development user as a site collection administrator for the http://tfs/sites/defaultcollection site collection.
Additionally, add the users to Reporting Services with the Content Manager role.
Note: You could use domain groups with Team Foundation Server’s group membership to control security, but for now, let’s just add the two users explicitly.
On the development server (SPDev), connect to the TFS server and create a new Team Project.
Create the project, accepting the defaults. This configures the process template, source control branch location, and SharePoint WSS 3.0 team site.
Once the Team Project is created, create a new Visual Studio Console Application solution and add it to source control, choosing the location for the team project in the source control hierarchy.
This confirms that source control is functioning as expected. We chose to create a Console Application because we'll use this to confirm our build server is functioning. We'll cover how to go through the additional steps necessary to build SharePoint projects in an upcoming post.
After the Visual Studio project is created, right-click the project in the Team Explorer pane in Visual Studio 2010 and choose “Show Project Portal” to confirm that the TFS SharePoint project portal (WSS 3.0 out of the box) is functioning.
When you access the project portal, instead of reports you may see errors mentioning rsProcessAborted. This is typically because the warehouse has not been processed yet. Rather than waiting for the scheduled job to process the warehouse, you can manually process it. Go to the following service endpoint:
· Invoke the ProcessAnalysisDatabase service, providing “Full” for the processingType parameter.
· Invoke the ProcessWarehouse service, providing no values for the parameters.
Once the cube is processed, the portal will look like the following:
We've verified that we can create a new team project, add source to source control, and verified the team project portal is up and running. The last step is to verify that the build server is running by configuring a build.
Although the last verification step is to configure a build, the development machine is the only machine with the SharePoint 2010 binaries. As a result, the build server cannot yet be used to build SharePoint projects due to the missing dependencies. We will cover the specifics of configuring a build server with SharePoint 2010 build dependencies in an upcoming post. For now, let’s just create a simple class library project to check whether the build is working as expected.
Create a folder called DROPS and give read/write access to the TFSBUILDS and TFSSERVICE accounts. Normally, you create this share on the build server, but you could create it on the TFS server or another server just as easily.
You can also grant access for users that will read from the share. For instance, you might have a domain group that your development team belongs to; just provide read permission to the network share for that group.
On the development machine, right-click the Builds node in Team Explorer and choose New Build Definition. When the new build definition asks you for the location to place builds, type your share name. For now, use the defaults for all of the other build definition values.
Right-click the build definition in Team Explorer and choose Queue New Build. Our build server is used for the build.
Tip: Be sure to check the console application project and its .sln file into source control. The build controller cannot build your project unless it can obtain the source from source control.
Open the DROPS share location and verify that the console application EXE and build log are available in the folder.
We did a LOT of configuration in this post. We created a new TFS server, a separate build server, and a separate test server. We verified that reporting services functions correctly, that the SharePoint portal shows the report data, and we verified that the builds are functioning correctly. In future posts, we'll expand on several of these areas including: configuring the build server to build SharePoint 2010 projects, automating build deployments, and configuring tests as part of the build process.
Scenario: Installing Team Foundation Server on a Single-Server.
Accounts Required for Installation of Team Foundation Components
Latest Updates Available for Team Foundation Server 2010
Set Administrator Permissions for Team Project Collections
How to Build SharePoint Projects with TFS Team Build
Building Visual Studio SharePoint Projects using Team Foundation Build