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
At the moment it is only possible to link only Bugs to Builds directly. Other assignables (User Stories, Features, Epics) can be attached to Builds via Relations. Ability to attach any work item to a build is coming soon (ETA is March 2020).
If you open a details view of any Bug you will see 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 belong 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.
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:
It is not possible to disable Builds as entity types in the system completely.
a sales representative
Get a live
Let one of our product specialists create your account
and shape Targetprocess for your company needs.