Sanplex provides comprehensive features for managing product branches and platforms. The main characteristics include:

• Broad Compatibility: The multi-branch and platform functionality is compatible with projects of all sizes. Projects and executions can be linked to specific product branches or platforms.
• Flexible Management: You can treat branches and platforms as time-based concepts. Different time phases can generate different branches or platforms.
• Merge Capabilities: Sanplex supports merging completed branches and platforms into the trunk or other existing branches.
• Independent Operations: With the exception of the trunk, management across different branches and platforms is mutually independent to prevent data confusion.

Product Managers can watch the following video to learn how to manage product branches and platforms in Sanplex:

【视频介绍】

Using a multi-branch product as an example, we will detail the enhanced branch and platform capabilities below.

I. Manage branches for multi-branch products

1. Set the product as multi-branch

When adding a new product, select the "Multi-branch" or "Multi-platform" option as the product type.

图1

2. Configure product branches

Navigate to Product > Settings > Branch List to view and manage branches.

The system automatically generates a default "Trunk" branch. The trunk branch cannot be edited or deleted.

3. Create a new branch

Click the Create Branch button in the upper right corner of the branch list to open the creation modal. Enter the branch name and description, then click Save.

图2

4. Edit a branch

Click the Edit button in the branch list to modify an existing branch. You can update the branch name, status, and description. Once a branch is successfully created, its default status is Active. You can edit this and change it to Closed.

图3

To batch edit branches, select multiple branches and click the Edit button at the bottom of the list.

图4

图5

5. Close a branch

You can close a branch by clicking the Close button located in the action column on the right side of the branch list.

图6

6. Sort branches

You can rearrange the order of branches by dragging and dropping them within the list.

图7

Once sorted, this new order will be applied to all branch dropdown menus across the system.

图8

7. Merge branches

The trunk cannot be merged into other branches. If you select the trunk branch in the list, the merge button at the bottom will not appear. The merge button only displays when you select other standard branches.

图9

Clicking the merge button allows you to merge the selected branches into an existing unselected branch. This action will consolidate all corresponding releases, plans, builds, modules, stories, bugs, and test cases into the target branch.

图10

Alternatively, you can merge them into a brand-new branch. Check the "Create Branch" option, enter the new branch name and description, and click Save to merge the data into this newly created branch.

图11

After clicking Save, the system will prompt you for confirmation. Please proceed with caution, data cannot be recovered once branches are merged.

图12

II. Manage branch modules

After setting up branches, you can manage the modules under each branch. The process is similar to managing standard product modules.

1. Add modules to a branch

Navigate to Product > Settings > Modules to create and manage modules for the current branch.

图13

You can switch the branch name in the product dropdown to create modules for other branches.

图14

2. Module and branch name display settings

For multi-branch products, an additional "Branch Name" display option is available. Click Display Settings beneath the module tree to configure whether the module name and branch name should be visible in lists.

图15

图16

If both are set to display, the story list page will visually indicate both the branch and the module for each item.

图17

III. Create twin stories for multi-branch/platform products

Multi-branch and multi-platform products support the creation of "Twin stories." This feature allows you to create identical stories across different branches or platforms. The content remains synchronized between the twins, but their statuses operate independently. This allows you to plan development tasks for the same story on different branches or platforms simultaneously.

1. Create twin stories

• In a multi-branch or multi-platform product, click Create Story. Click the [+] icon to select multiple branches, and assign the corresponding modules and plans.
• After clicking Save, Sanplex will create one story per branch. These stories share a twin relationship.
• All fields remain synchronized between twin stories except for product, branch, module, plan, and phase.

图18

2. View twin stories in the details page

The first story in the twin group (highlighted with a theme color tag) serves as the current active story. You can view the other twin stories directly from the details page.

图19

3. Unlink twin relationship

Hover your mouse over a twin story to reveal the Unlink button. Click it to sever the twin relationship for this specific story. This action cannot be undone.

Once unlinked, the story's content will no longer synchronize with its former twins.

Unlinking one story does not affect the twin relationships among the remaining linked stories.

图20

4. Unlink during story changes

You can also choose to unlink a story directly during the change process. Once unlinked, the change workflow and updated content will not sync to the other twins.

图21

IV. Branch association logic with other features

Branches can be associated with stories, modules, plans, and releases. They can also be linked to builds, bugs, and test cases. Projects and executions can be associated with specific product branches to facilitate story development.

1. Module display and selection logic

When creating or editing stories, bugs, or test cases under the Trunk branch, you can only select Trunk modules.

When working under Branch 1, you can select modules from both Branch 1 and the Trunk.

Regarding data upgrades: Stories, bugs, and test cases will be uniformly assigned to the branch associated with their current module after an upgrade.

Taking stories as an example: When creating a Trunk story, you can only select modules under the Trunk.

图22

After switching to a non-Trunk branch, you can select modules from both the Trunk and the current branch.

图23

2. Plan display and selection logic

2.1 Linking stories to plans:

• When creating a story and linking it to a plan, you can only link it to unexpired sub-plans under the current branch.
• When linking a plan to stories, a Trunk plan can only link to Trunk stories.
• When linking a plan to stories, a Branch 1 plan can link to both Trunk and Branch 1 stories.

2.2 Creating plans:

• When creating a plan, you can associate it with multiple branches. Sub-plans can only be selected within the branch scope of their parent plan.
• If you modify the branches of parent and sub-plans, the stories and bugs within those plans will also be removed.

2.3 Linking projects and executions to plans:

• After selecting branches for projects and executions, you can link them to plans.
• For example: Suppose a project includes the Trunk, Branch 1, and Branch 2. A plan includes the Trunk, Branch 1, and Branch 3.
• After linking the project to the plan, the project can only link to the Trunk and Branch 1 stories within that plan.

3. Logic for linking builds to stories and bugs

• When linking a Trunk build to stories, the default list (without clicking search) displays Trunk stories that are already linked to the execution but not yet linked to any build. Clicking search will query all Trunk stories.
• When linking a Trunk build to bugs, the default list (without clicking search) displays Trunk bugs under the execution that are not yet linked to any build. Clicking search will display all Trunk bugs. (It no longer distinguishes the execution linked when the bug was submitted.)
• When linking a Branch 1 build to stories, the default list (without clicking search) displays Trunk and Branch 1 stories linked to the execution but not yet linked to a build. Clicking search will query all Trunk and Branch 1 stories.
• When linking a Branch 1 build to bugs, the default list (without clicking search) displays Branch 1 bugs under the execution that are not yet linked to a build. Clicking search will display all Trunk and Branch 1 bugs.
• Taking the linking of builds to stories as an example to illustrate the above logic: On the page for linking a Trunk build to stories, the list displays stories linked to the execution but not yet linked to the build under the Trunk branch before searching. After clicking search, it lists all stories under the Trunk branch.

图24

4. Logic for linking releases to stories and bugs

4.1 Product releases linking stories and bugs (Trunk)

• Linking stories: By default, the page displays the Trunk stories of the current product. Searching also displays Trunk stories.
• Linking bugs: By default, the page displays bugs under the Trunk of the current product. Searching also displays bugs under the Trunk.

4.2 Product releases linking stories and bugs (Branch 1)

• Linking stories: By default, the page displays Branch 1 and Trunk stories of the current product. Searching also displays Branch 1 and Trunk stories.
• Linking bugs: By default, the page displays bugs under Branch 1 and the Trunk of the current product. Searching also displays bugs under Branch 1 and the Trunk.

4.3 Project releases linking stories and bugs (Trunk)

• Linking stories: By default, the list shows Trunk stories associated with the product to which the build belongs. Searching lists all Trunk stories under the current product.
• Linking bugs: By default, the list shows bugs under the Trunk associated with the product to which the build belongs. Searching lists all bugs under the Trunk for the current product.

4.4 Project releases linking stories and bugs (Branch 1)

• Linking stories: By default, the list shows Trunk and Branch 1 stories associated with the product to which the build belongs. Searching lists all Trunk and Branch 1 stories under the current product.
• Linking bugs: By default, the list shows bugs under the Trunk and Branch 1 associated with the product to which the build belongs. Searching lists all bugs under the Trunk and Branch 1 for the current product.

4.5 Default listing scope for linking legacy bugs

It lists bugs under the trunk or branch of the product associated with the current release. The creation date of these bugs must fall within (or equal) the start and end dates of the execution associated with the build. Furthermore, these bugs must be active, or their resolution date must be later than the end date of the execution associated with the build. Additionally, they must be bugs not yet linked to the current release.

4.6 Default listing scope for linking resolved bugs

It lists bugs under the trunk or branch of the product associated with the current release. The resolution date of these bugs must be later than the start date of the execution associated with the build, and they must belong to the execution of the current build. Alternatively, if they do not belong to the execution of the current build, their creation date must be earlier than the start date of the execution associated with the build. They must also be unlinked to the current release.