Create or edit a build definition

After you have deployed your build system, you are ready to define a build process that compiles your code, runs your tests, and performs many other important functions for your team.

1. From Visual Studio, Team Explorer, make sure you are connected to the team project (Keyboard: Ctrl + 0, C), and then open Builds (Keyboard: Ctrl + 0, B).

2. Choose the New Build Definition link or select a build, open its shortcut menu, and choose Edit Build Definition.

   Tip

   If a TF225001 error message appears, configure a build controller.

3. 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).

4. 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 allow new builds to be queued by triggers or users, but to leave these builds in a paused state.

   • Disabled prevent new builds from being queued by triggers or users.

5. On the Trigger tab, specify the event that you want to cause this build definition to be run. See Specify build triggers and reasons.

6. On the Source Settings tab:

   • TFVC: 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. See Work with build workspaces.

   • Git: Specify the repository and the branches that contain the files that your build process requires.

     Tip

     In the list of branches monitored for continuous integration (CI) and rolling builds, you can use wildcards. For example, you could specify refs/heads/feature* to monitor the refs/heads/featureA and refs/heads/featureB branches.

7. 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 Visual Studio Online and your team’s needs can be met by a single standard build agent, select Hosted Build Controller. See Hosted build controller.

8. 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. See Select a staging location and set up a drop folder.

   • Copy build output to the server: Choose this option to copy the built output to your Team Foundation Server.

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

   • To define a simple build, choose Show details, and then in the Build process file list, choose Default Template. See Use the Default Template for your build process.

   • 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. See Customize your build process template.

10. 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.

11. 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. See Run, monitor, and manage builds.