A Build is an important part of the continuous software delivery process. Usually it represents a set of new features and bug fixes that are going to be released to the end users. By attaching work items to builds you can easily track which items were released in a particular software version. For this purpose we recommend to use Build entity, not Release.
Attach Work Items to a Build
When the new version is prepared, create a new Build in Targetprocess. New Build can be created using the main +Add button:
Direct links between Builds and Work items
It is possible to link Bugs, User Stories, Requests, Features, and Epics to Builds directly. Other assignables can be attached to Builds via Relations.
If you open a details view of any Bug you will be able to find Build field in the Info section:
Relations between Builds and Work items
In Targetprocess v3.13.13 it is possible to attach Features, User Stories, Bugs to Builds via Relations.
Then attach it via Relations to all released Features, User Stories, and fixed Bugs that are released in this Build.
To see the detailed information of all the Builds, you can use a Board View with Outbound (or Inbound) Relations filtered by Build entity type:
Relations between Builds and Projects
A Build always belongs to just one Project (Product). However, a Build may contain attached and related work items from as many Projects (Products) as possible.
Inheritance of Releases and Iterations in Builds
Originally, the Build entity type was created for the testing area. It was used to track the build a defect was found in and a test plan run has been executed.
A Build can be assigned to a Release and a nested Iteration.
Releases and Iterations are supported as lanes on views that display Builds as cards. Detailed views of Releases and Iterations do not have Builds tab.
A Build cannot be assigned to a Team Iteration.
Release and Iteration are inherited for Test Plan Runs from Builds. When you assign a Build to a Test Plan Run, an Iteration and Release of the Build are assigned to the Test Plan Run automatically. When a Test Plan Run is assigned to a Release or an Iteration, you can assign it to a Build from the Release / Iteration only.
Release and Iteration of Bugs are independent from the ones assigned to a related Build.
Builds are supported as lanes on views that display Test Plan Run as cards. Builds are incompatible with Bugs this way.
Unfortunately, Bugs and Test Plan Runs are not displayed as tabs in detailed views of Builds.
Statuses of Builds
The Build entity does not have its own Workflow. Though, when it is necessary to track the status of Builds, Custom Fields of Drop Down type can help:
Configure Role-based Permissions and project membership settings to add/remove the ability to create/edit/delete Builds.
It is not possible to disable Builds as entity types in the system completely.
Still have a question?
We're here to help! Just contact our friendly support team