A Visual Studio 2008 edition that supports Team Foundation Server.
Creating a Build Agent:
Start out by opening the Team Explorer window, which can be done by navigating through the menu View –> Team Explorer. A list of solutions may appear, but if not, click on the icon highlighted in the image below and select the Team Portal project as appropriate.
Expand the Builds folder that is one level deep within the Team Portal project. Upon right clicking on the Builds folder, the following menu will be displayed. The starting point is Build Agents, so click on Manage Build Agents.
A new window will appear that allows the creation of new and editing of existing build agents.
After clicking New, a popup window displays asking for the properties and configuration to create the new build agent. The default values are shown below.
- Fill out a display name for the build agent. This build agent can be used with multiple build definitions, as will be shown below.
- Enter the name of the build server.
- Optionally change working directory to be used on the build server. Using a shared location on the build server can be useful for team members to troubleshoot.
After clicking okay, the newly created build agent should appear in the create and edit screen.
Creating a Build Definition:
Now that a build agent is created, a build definition needs to be created and associated with the build agent. In Team Explorer, under the Team Portal directory, right click the builds directory again and click on New Build Definition.
The initial screen shown below is what should be shown, which will allow for entering all of the required information for a build definition.
Enter a verbose name for the build definition. For the continuous integration build definitions, appending something like “_CI” may be helpful. If you would like multiple branches to be built separately using continuous integration, appending something like “_Trunk_CI” may be helpful.
On the next tab, one or more Source Control Folders may be set up. The only need for multiple would be in the case that solutions reference other solutions within the TFS structure. If branching is used, be sure to narrow down the Source Control Folder to the appropriate level. It may be useful to have all branches handled through a single build definition, but I prefer to have them individually set up.
If you actually select the text within the Source Control Folder, an ellipsis button will appear allowing you to select the appropriate location through a select folder popup.
On the project file tab, you will see something similar to the following. It should automatically populate the version control folder using the information previously provided, but it will warn about needing to actually create the file. Click the create button, which will add the folder TeamBuildTypes at the root level of Team Portal and create the necessary MSBuild files. Note that these files and folders are added to source control. The next few screen shots will walk through the creation process for the MSBuild project.
If the Source Control Folder you entered contains more than one solution file, you will see a list of all available solutions to build. Select all that you want to build as part of this build definition.
Under the configurations tab, select all of the target configuration you want to build during this build definition. For example, Release, Debug, Staging, etc. and any Platform combinations that may be appropriate.
Within the Options tab, you can set up which automated tests are to be executed and if code analysis should be run. Note that in order for these to run on the build server, Visual Studio must be installed, as the MSTest framework and Code Analysis settings are not part of TFS.
After clicking Finish, we are brought back to the build definition window and the warning should be replaced with the message “Found MSBuild project file”.
In the source control explorer window, you should now see newly created MSBuild folder directory beneath the top level Team Portal folder.
A list of files within the directory show that the wizard created two files. The *.rsp is not in a human readable format, but the *.proj file is the MSBuild XML file that may be of interest for customization at a later point.
The next tab in the build definition creation is for setting up how long each type of build result should be kept. By kept, it means storing the full source, test results, code analysis and anything other that may be part of the build process. The only real concern here is disk space on the build server. Remember that if you have many solutions using continuous integration on the build server this may become an issue. It may take an extra step or two, but since the code is always stored in TFS, you can rebuild from any point in history.
The next tab is how the build definition and previously created build agent are tied together. Select the build agent from the drop down menu. The new button will allow you to create a build agent as part of the build definition creation process, but for the sake of this post, I’ve separated the two. The text entry area is asking for the place to copy the output from the build process. Generally, I leave it on the build server, but any network location will work. If you refer back to the folder location I used for the build definition’s working folder, you can see I’ve created a share on the build server called “builds”. Within the builds directory are two sub-directories, “completed” and “working”. The working folder is where each build agent executes the assigned build definitions. The completed folder is where the output from the build definition is copied. Within each of the sub-directories, I have folders that match the build definition. The output created from the build definition automatically is contained in a generated folder name that includes a timestamp, so there is no worry of things getting overwritten.
The last tab in creating a build definition is to specify how the build will be triggered. You can have it as a manual process, after each check-in or accumulated check-ins, or even specify specific recurrence patterns like a nightly build.
From the Team drop down menu, select Project Alerts.
The following window will then allow selecting which types of alerts you would like to receive. By default, the email address and HTML format are already populated.
For full control over the alerts, go to the Team drop down menu and select Alerts Editor.
The following tabbed window will open and allow for full customization and creation of alerts. As shown, you can create combinations using AND and OR criteria in the alerts definition.
Testing the new Build Definition and Build Agent:
Going back to the Team Explorer window and within the Team Portal –> Builds directory, right click on the newly created build definition. Then click Queue New Build.
The Queue Build window should appear. No changes should be required. Just click “Queue”.
After clicking “Queue”, the Build Explorer tabbed window should be open. This window allows for filtering by build definition, status and agent.
- Red ‘X’ = Failed
- White circle with a Green Arrow = In Progress
- Three white overlapping squares = Queued
- Green Check = Success
The Build Explorer window has two tabs that can be navigated to at the bottom. Once builds are finished, the are automatically removed from the Queued tab and moved to the Completed tab.
By double-clicking on the build line entry, the details will be opened in a new tabbed window. From here, access to the log can be found through the linked file located in the targeted drop location. The full BuildLog.txt can be quite large.
The Release.txt is usually much smaller and can be found by expanded the Result details and clicking the Release.txt link.
A lot of customization can be applied to the build process. I’ve found the following book very helpful.
|Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build (PRO-Developer)|
If you’re wondering why your Visual Studio may have less options than in some of my screen shots, it may be because I have the Visual Studio Team System 2008 Team Foundation Server Power Tools – October 2008 Release installed. That install is not required for the purpose of this post.