Overview
Builds in the Deployment Server context represent a structured setup where customers can deploy, manage, and test their projects or designs across different environments. A Build acts as the central package for tracking, managing, reviewing, auditing, and shipping work across environments.
This setup ensures that all necessary steps for transferring projects are handled efficiently and with confidence, minimizing risks during deployment. Each build is stored under a specific Deployment Package within an organization’s Deployment Folder, offering full traceability from development to production.
Builds can be accessed through the Deployment Server UI by navigating to: Organizations > Deployment Folder > Deployment Package.
Build Metadata
Each build contains the following fields to support versioning, traceability, and quality control:
| Field | Description |
|---|---|
| Build ID | A unique identifier automatically assigned to the build. |
| Project | The name of the project the build belongs to. |
| User Story | The specific user story associated with the build. |
| Unit Tests | Status of unit test execution (with visual indicator). |
| QA | Status of QA review and approval (with visual indicator). |
| Timestamp | Date and time when the build was created. |
Visual Representation of Build Accumulation
The following screenshots illustrate how the system handles build accumulation for the same Project - User Story combination.
In the example:
- Build #1, Build #2, and Build #3 all belong to the same project and user story.
- Build #3 includes:
- All work from Build #1 and Build #2
- Plus any additional changes checked in since the previous builds
The screenshots show how each build is versioned and how the latest build reflects a cumulative package of changes, ensuring consistency and completeness.
Unit Test Execution and Status Indicators
When a user story is checked in from the Development Environment, if unit tests are included, they are executed automatically. The result of this execution is reflected visually in the Builds list.
Unit Test Circle Indicators
| Icon | Meaning |
|---|---|
 | All unit tests passed successfully. |
 | One or more unit tests failed. |
 | No unit tests were included in the build. |
These indicators are shown in the Unit Tests column for each build.
Deployment to QA and QA Status Indicators
Once a build is listed in a deployment package, it can be manually deployed to the QA environment:
- Action: Right-click the build and select Deploy.
- This triggers a change in the QA column status.
QA Circle Indicators
| Icon | Meaning |
|---|---|
 | Build is deployed to QA, awaiting review. |
| Build approved by QA. |
 | Build rejected by QA. |
QA reviewers can either approve or reject the build after review. Their decision updates the visual status and determines whether the build can progress toward final release.
Deployment Package Readiness
A Deployment Package becomes eligible to be marked as Ready only when the following conditions are met:
- The final build for a Project - User Story has a Green Unit Test Circle, or no tests.
- The final build for a Project - User Story has a Green QA Circle (approved by QA).
- All user stories associated with the builds are in Approved status.
This ensures that only validated and tested code, reviewed by both automation and QA, moves forward in the deployment lifecycle.
Build Deletion and Rollback
Builds are immutable once created. Deletion or rollback is not supported to maintain a consistent audit trail and deployment history.