I am a developer at Microsoft and work in the .NET Common Language Runtime (CLR) team. For the last 4 years I have been working on virtual machine technologies on a variety of form factors including desktops (Windows, Linux), tablets (Win8), gaming-consoles (Xbox 360), mobile devices (Windows Phone 7, Windows CE, Symbian).I have worked on various core pieces of the runtime including Garbage Collector, memory manager, platform abstraction layer, runtime-performance, etc.Before working on .NET I worked on Visual Studio Team Foundation Server, Visual Studio Team System, Adobe Framemaker, Adobe Acrobat, Texas Instrument's Code Composer Studio.
The build type wizard is used to generate Build Types which are a collection of Build Scripts used to fire the remote builds on the Build Machines. These scripts are XML scripts consumed by MSBuild which is used by Team Build to build the user's solutions. Just as the local VS build works on solutions (.sln) and projects (.proj) Team Build works on Build Types.
You need to have the Team Explorer open (View->Team Explorer). There is couple of entry points in Visual Studio to the New Build Type Wizard. It can be launched by right-clicking on the Team Build node in the Team Explorer (under any Team Project) or through the menu Build->New Team Build Type. The later works only when a solution is open in VS (cause the top level Build menu comes up only when a solution is currently open).
In case you get a pop-up saying that "No workspace Exists for the Given team project". It means that there is no source control workspace on the client that maps into the Team Project. Change an existing workspace mapping or create a new workspace for the team project for which you are trying to create the build type.
You need to give a name to the Build Type. This is the only mandatory field on this page. Build Type name has to be unique for the Team Project.
The Wizard verifies the uniqueness of the name when you hit Next and gives an popup error message in case is finds another Build Type with the same name.
This is where you select the solutions you want to build for the Build Type. The combo box on top shows the names of the available workspaces with the name of the workspace owner in parenthesis. Select the workspace and all the solutions in the source control that are mapped in the workspace will be listed. Check all the solutions you want to build and use the arrow buttons on the right to set the order in which the solutions will be built. The ordering may be important if there are interdependencies between the solutions and one solution requires the binaries generated by another solution.
If you do not see any solutions listed, it means that there are either no solutions checked in to the source control or the workspace mapping is not correct.
You can give the configurations that will be built for each of the solutions. This is the same list that you see in through Build->ConfigurationManager. You can add as many unique combinations of Configurations and platforms you need. The platform list is pre-defined and can be any one of x86, x64, Itanium, Win32 and AnyCPU. Configuration can be Debug, Release or any other user defined configuration.
The solution should support the given combination i.e. you must have had added the same configuration/platform pair in Build->Configuration Manager for that solution for the build to succeed.
This is where you specify which build machine will be used and where the built binaries will be dropped (copied to). Type the name of the Build Machine (server name) without the leading \\.
The build directory is the local folder on the build machine where the sources are downloaded from the Team Foundation Server and built using MSBuild. This folder is created in case it is not already present. You have to give the local path of the build directory on the build machine (something like c:\builds). In case you are wondering why there is no browse button beside the folder name the reason is that the folder is a local folder on the build machine and will not be browsable from the client machine where you are creating the Build Type. This is more of a internal detail that has been exposed. For all normal purposes you will not be needed to be bothered about the build folder.
Both the build machine and the build directory can be overridden at the time of firing the build.
The drop location is the place where the binaries will be copied to once the build is over. You need to create a folder on a server and share it out with write permission to Everyone and then type the name here. This needs to be in UNC format (\\server\share). You can browse for the share on the network. In case you forget to share out the folder with write permission then build will fail.
In case you fail to browse for the drop location try browsing to the same machine using "My network places"->"Entire Network" in Windows explorer. Most probably you'll see the same error as the one you saw in the Wizard. Call your network admin to fix issues with your permission settings or any other network issues.
Though this page is named Build Steps you can only change the test related steps through this page. Check the Run Test checkbox if you have a test project in your solution and would like to run the tests in it once the solutions are built. The test metadata file and test list become mandatory fields if the run tests check box is checked. All the vsmdi files in the Team Project will be listed here. Select the once you want to use to test. The test list combo box will be automatically updated to show all the test lists in the vsmdi file. You can choose any one of the test list or use the default "All loaded tests".
If no vsmdi files show up in the combo box then there are no such files checked into source control. You will be needed to create test projects check them in to source control and try creating the Build Type again.
Check the perform code analysis check box if you want to run FxCop for static analysis of the source code.
Finally this is where the Finish button gets enabled. Review the selections you had made in all the pages, pray to god and hit the Finish button
Team Build generates the build scripts and some associated helper files and checks them in. If the Build Type name in MyBuildType then this is what is created and checked into source control
$/MyTeamProject/TeamBuildConfigurations/MyBuildType/TeamBuild.proj This is the main build script file that is generated by team build $/MyTeamProject/TeamBuildConfigurations/MyBuildType/CustomAction.targets This file is included by TeamBuild.proj and is used for customizing team build to suit your organizations
A node named MyBuildType is created under the Team Builds node in the Team Explorer and the created TeamBuild.proj file is downloaded to a temporary file and opened in Visual Studio. Note that this is a temporary copy and changes made to it are not reflected on the server. I will post some time later on how to modify the teambuild.proj file.
Right-click on the newly created node (MyBuildType) and then in the context menu choose "Build Team Project <MYTEAMPROJECT>". In the dialog that opens click on the Build button. If all is well, build should start and the Build Summary page should come up. Double click on the name of the build just fired and see the detailed report.
In Beta 2 the summary and the detailed report does not auto refresh. So you need to manually refresh the pages using the refresh button on top of the Summary page or the context menu of the detailed report page. When the build complets click on the drop location link on the detailed report and the folder with the binaries just built will come up.