Team Foundation Build uses the concept of build types. A build type is simply the container for all the configuration information related to a build. In essence, it defines all the different parts of a particular build. You create a new build type by using the Team Explorer window. Right-click the Team Builds node and then select New Team Build Type. This will launch the New Build Type Creation Wizard. Specifying New Build InformationThe wizard will ask a series of questions about the desired build process. After you've provided the answers, the wizard will write them out into a specific file format used by the build engine. Naming the BuildThe first step is to provide a name for the build. This is the same name that is reflected within the Team Explorer Builds node and in the build reports. Figure 23.4 shows the first page in the build type wizard. Figure 23.4. Specifying the build type name.Selecting the Solutions to BuildThe second step involves selecting the projects that you want to be included as a part of the build (see Figure 23.5). The drop-down at the top of the wizard page is used to essentially filter the list of available projects based on a given workspace (refer to Chapter 19, "Source Control," for a discussion of workspaces). Every solution that exists in the workspace selected in the drop-down will be displayed in the list box. Checking or unchecking the individual solutions will include or exclude them from the build. Figure 23.5. Selecting the projects to build.Note that this page of the wizard also allows you to specify the order of the build. The order is important in cases in which there may be an order dependency between the different binaries generated between solutions. You change the build order of the solutions by using the up and down arrows next to the list of solutions. Selecting the Build ConfigurationsBuild configurations dictate parameters for the build such as whether this is a release or debug build, and what the target CPU platform is. You can specify multiple configurations on the third page of the wizard (see Figure 23.6); they will be built in the order shown. Figure 23.6. Selecting the build configuration.Providing a Build LocationTeam Foundation Build will need to know which server to use as the Build server. Remember, you must have already prepared this server as a Build server by running the appropriate setup files from the Team Foundation Server install media; this will deploy the build service onto the server (which must, of course, be running before you can start a build). The build engine will need to know where to place the build files locally on the Build server and where the build output should be published so that the team can access it. All of these parameters are captured on the Location page of the wizard, shown in Figure 23.7. Figure 23.7. Supplying location information for the build.Selecting Build TestsTests can be run as part of the build process. This next page of the build type wizard (see Figure 23.8) gathers information on which tests should be run during or after the build process. By selecting a test metadata file, you can pick and choose from among any of the tests defined within the Team Project (team project tests were covered in the preceding chapter). Figure 23.8. Options for testing the build.By using the bottom check box, you can elect to run static code analysis against the source files included in the build. Confirming Your SelectionsThe sixth and final page of the New Team Build Type Creation Wizard (see Figure 23.9) summarizes all the build definition selections you have made. Figure 23.9. Validating the build type information.Clicking Finish will do two things: It will write the various build settings into an XML file called TFSBuild.proj, and it will add that XML file to the source control system within a new project that is named the same as the build. For instance, Figure 23.10 shows two new build projects as they appear within the Source Control Explorer window. They are located under the team project node and then within a folder labeled TeamBuildTypes. Figure 23.10. Build type files in the Source Control Explorer.Editing a Build TypeTFSBuild.proj is an XML file used as input to the MSBuild engine. Visual Studio Team System does not offer a user interface for making changes to a build after it has been initially defined. To do this, you need to directly edit the TFSBuild.proj file. The TFSBuild.proj Project FileListing 23.1 shows the results of a complete sample AdventureWorks build type as it is represented within the TFSBuild.proj file. Reading through the XML, you will notice that it has captured all the major build type information categories within its individual nodes: There are nodes for storing general build, solution, configuration, location, and test option information. Tip You are not limited to a stock set of build tasks. It is fairly straightforward to extend any given build type with custom tasks that will run during the build process. Because a task is really just a body of code that is executed during the build, creating a new task involves writing code to implement your custom action. For information on how to extend a build using custom tasks, see the MSDN topic "Walkthrough: Extending Team Foundation Build." The XML in the build project files is extremely well commented, and the files are fairly short. Editing a build project file is straightforward and simple. As an example, if you wanted to change the server used as the Build server, you would edit the following XML node: <BuildMachine>NewBuildServer</BuildMachine> Listing 23.1. Sample Build File
Note To open the build project file in Visual Studio, you either right-click on the build type in the Team Explorer and select View Build Type, or navigate to the specific TFSBuild.proj file in Source Control Explorer and double-click on the filename. The Role of MSBuildAs mentioned earlier, the core of the TFS Build server is a technology called MSBuild. This build engine is implemented in a single executable, msbuild.exe. Although MSBuild ships with Visual Studio, it does not have any dependencies on the IDE, which means you can run the file on machines that don't have the development environment installed. In fact, MSBuild may actually be distributed within future operating systems from Microsoft, such as Microsoft Windows Vista. MSBuild works by taking in an XML file that describes the sequence of events for the build. It then processes those events in the order specified. MSBuild is a robust engine in that it can handle conditional builds, incremental builds, and dependencies between targets and builds. Because the TFSBuild.proj file conforms to the MSBuild specifications for its input file, Team Foundation Build is able to simply pass this file over for execution when the build is kicked off. In summary, Team Foundation Build overlays the MSBuild engine with a user interface and a series of functions to integrate the build into the overall fabric of the project team (thus allowing for notifications, changeset selections, and so on). |