Export (0) Print
Expand All

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 Icon 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 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 icon TFVC: In the Working folders table, specify the version-control folders that contain the files that your build process requires.

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

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

      Tip 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. For more information, 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 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 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. 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 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.

Show:
© 2014 Microsoft