Create a Build Definition

After you put a build system in place (as described in Setting up and Managing a Build System), you are almost ready to start using Team Foundation Build to compile your code, run your tests, and perform many other important functions. The next step is to create a build definition. A build definition contains your instructions about which code projects to compile, which additional operations to perform, and how to perform them.

Required permissions

You must have the Edit build definition permission set to Allow. For more information, see Team Foundation Server Permissions.

To create a build definition

1. In Team Explorer:

   1. If you are not already connected to the team project that you want to work in, then connect to the team project.

   2. Choose Home, and then choose Builds.

   3. On the Builds page, choose New Build Definition.

   A new build definition window appears.

2. On the General tab:

   • In the Build definition name box, specify the name to associate with the build definition. See Naming Restrictions in Team Foundation.

   • (Optional) In the Description box, add an appropriate description. This description provides additional information to people on your team when they are about to manually queue a build (as described in Queue a Build).

3. If your build process is not yet ready for your team to use, on the General tab, under Queue processing, you can change the default setting of Enabled to:

   • Paused to cause the system to allow new builds to be queued by triggers or users, but to leave these builds in a paused state.

   • Disabled to cause the system to prevent new builds from being queued by triggers or users.

4. On the Trigger tab, specify the event that you want to cause this build definition to be run. For more information, see Specify Build Triggers and Reasons.

5. On the Source Settings tab, in the Working folders table, specify the version-control folders that contain the files that your build process requires.

   Tip

   To ensure that your build process functions correctly and to improve performance, include all folders, and only these folders, that contain files that your build process requires. For more information about how to specify these folders, see Work with Build Workspaces.

6. On the Build Defaults tab, if more than one build controller appears in the Build controller list, choose the build controller that you want the build system to use to process this build definition.

   If your team project collection is hosted on Team Foundation Service and your team’s needs can be met by a single standard build agent, select Hosted Build Controller. See Use the Hosted Build Controller in a team project collection hosted on Team Foundation Service

7. On the Build Defaults tab, choose one of the following Staging location options to specify how you want the build process to produce and store output files such as compiled binaries and log files:

   • This build does not copy output files to a drop folder: Choose this option if you do not need output files.

   • Copy build output to the following drop folder: Choose this option if you want to copy output files to a drop folder on a file share server. In the box, type the UNC file path to the folder where you want the build system to put the output files. You must specify a folder that has been prepared for use as a drop folder. For more information, see Select a Staging Location and Set Up a Drop Folder.

   • Copy build output to the following Source Control folder: Choose this option if you want to copy output files to a drop folder in version control. In the box, type the path to the folder (or choose … to browse for the folder) where you want the build system to put the output files. You should use care in specifying this folder, and there are constraints on which folder you can specify. For more information, see Select a Staging Location and Set Up a Drop Folder.

8. On the Process tab, specify details about what functions this build performs and how it performs them:

   • To define a build quickly and easily, choose Show details, and then in the Build process file list, choose Default Template. Review and modify the values of the Build process parameters as necessary. For more information, such as explanations of the Build process parameters and how to use them, see Define a Build Process that is Based on the Default Template.

   • If your team has defined a custom template that you want to use, choose Show details, and then, select the template in the Build process file list. Review and modify the values of the Build process parameters as necessary. Or, you can create your own custom build process. For more information, see Create and Work with a Custom Build Process Template.

9. On the Retention Policy tab you can specify how many completed builds you want to keep. You can modify two sets of retention policies in the Specify how builds should be retained list and to meet your team's needs:

   • The Triggered and Manual group of policies limit what the system keeps from those builds that were queued either manually or by an automatic trigger.

   • The Private group of policies limit what the system keeps from those builds that were queued either manually from source code in a shelveset (as described in Queue a Build).

   To modify a retention policy for Stopped, Failed, Partially Succeeded, or Succeeded completed builds, perform either or both of the following steps:

   • Choose the value in the Retention Policy column, and choose one of the following options: Keep All, Keep Latest Only, Keep 2 Latest, Keep 5 Latest, Keep 7 Latest, Keep 10 Latest, or Specify Count to Keep.

   • Choose the value in the What to Delete column, and choose a value. For more information about these values, see Delete a Completed Build.

10. When you finish working on the build definition, on the File menu, choose Save<Name of Build Definition> (Keyboard: Ctrl+S).

    The build definition you created appears on the Builds page in Team Explorer. For more information, see Run, Monitor, and Manage Builds.