In software delivery, a build is a potentially testable package produced during development. A build does not necessarily include everything intended for a release; it represents the work completed up to the current point in time.

The primary purpose of builds is to define a clear test scope, facilitate collaboration between developers and testers, and support scenarios such as multi-version delivery and bug-fix validation.

(Optional note: If your team prefers to use the term “Version” instead of “Build” for management purposes, you can rename the UI term via Admin > Secondary Development > Language Items and update the corresponding language entry for “Build” under the Execution menu.)

When several requirements are implemented or bugs are fixed, you can create a Build in Execution > Stage > Builds to package the completed work. When creating a build, you need to specify the Product and the Application it belongs to. In Sanplex, a single product can include multiple applications, and each application is an independent deliverable.

• Application vs. Build: An application is an independent deliverable under a product and is typically the smallest releasable unit in Sanplex. A build is a testable (or tested) package; it may pass or fail testing. An application may include multiple tested builds. Since releases are often delivered “as needed,” a release may include the contents of multiple builds—or a single consolidated build—within the same application. In practice, you usually release the application (or an integrated application) rather than releasing individual builds.
• Relationship between Release, Application, and Build: A release may include multiple applications, and an application may include multiple builds. The simplest scenario is: one release > one application > one build. (应用介绍链接)

To learn how to create builds and submit them for testing in Sanplex, watch the video: [Video link—Sanplex version to be provided]

视频介绍

1. Create a Build

1.1 Create a Build

After the development team completes some requirements or fixes some bugs, they can create a tag in the code repository (for example, Git/SVN/GitLab).

The Project/Execution Lead (or the Release Owner, if your process defines this role) can create a build in Project/Execution > Builds.

图1

When creating a build:

• If the project/execution is linked to only one product, the product name is displayed directly.
• If multiple products (or multiple branches of one product) are linked, switch the target product/branch using the dropdown list.

Applications can be managed in the application list under product releases.

图2

1.2 Link Requirements and Bugs

After the build is created, use the Link action to associate Requirements and Bugs with the build. The linked requirements and bugs define the test scope for the QA team.

图3

• After clicking Link Requirements, Sanplex lists requirements in the execution that are not yet linked. Select the items and click Link Requirements to complete the association.
• Linking bugs follows the same process.

图4

After linking requirements and bugs successfully, you can view them in the build list.

图5

Additional notes on linked item categories (typical system filters):

• Completed Requirements: requirements that are marked as developed/completed and can be linked to the build.
• Resolved Bugs: bugs that are resolved and whose Fix Build/Resolved In points to the current build.
• Newly Found Bugs: bugs that are active and whose Found In/Affected Build points to the current build.

1.3 Maintain Builds

Build maintenance includes editing build details and deleting builds. Use Edit and Delete actions as needed.

图6

You can also open the build detail page and click View Details.

图7

2. Create an Integrated Build

An Integrated Build is used to package requirements and bug fixes completed across multiple iteration builds for integration testing.

Integrated builds take effect only at the project level. When creating a build under a project, you can choose whether it is an integrated build.

If an integrated build is selected, you can link multiple iteration builds into the integrated build.

图8

After you select multiple included builds, the related completed requirements, resolved bugs, and newly found bugs from those builds are automatically aggregated into the integrated build. Other functions are the same as a standard build.

图9

3. Submit for Testing

After linking requirements and bugs to a build, you can submit it for testing by creating a Test Request.

图10

Click Submit for Testing in the action column on the right side of the build list to open the Create Test Request page.

If earlier builds in this project/execution were previously submitted for testing and test reports were generated, those related test reports will be listed for reference to support this round of testing.

图11

You can view the created test requests in Project/Execution > Testing > Test Requests. After a test request is created, notify testers to begin validation.

图12