Skip to content

6. Build & Release Freeze
What Freezing the release branch and handing a build to QA through a mandatory Build Ticket.
Owner Engineering (declares complete and freezes), DevOps (produces or deploys the build).
Triggers When development declares the release content complete.

Summary

When development for a release is complete, the release branch is frozen: no further feature development goes into it. A build is then produced (an APK or equivalent for mobile, or a deployment to the dedicated QA environment for backend) and handed to QA. The handover is not informal. It happens through a mandatory Build Ticket in the tracker that captures everything QA needs to accept and test the build, with every resolved ticket linked to it. QA does not accept a build that arrives without a complete Build Ticket. By this point QA's test plan has already been authored and approved at Test Case Design & ITCR; the build is simply what QA executes that approved plan against.

Full detail

Freezing the release branch

Once dev declares the release content complete, the release branch is frozen. From this point:

  • No new feature work enters the branch.
  • The only changes allowed are bug fixes for issues QA finds, via bug/<ticket> branches off this same release branch (see Defect Handling).

Two different freezes, do not confuse them

The release-branch freeze here stops development so QA can test against a stable target. Bug fixes still flow in. This is separate from the production tag created later at Tagging & Deployment, which is the immutable, permanent record of exactly what shipped. The freeze is a working state; the tag is a permanent snapshot.

Producing the build

  • Mobile: produce the build artifact (for example an APK) from the frozen release branch.
  • Backend: deploy the frozen release branch to the dedicated QA environment.

The build MUST be produced from the frozen release branch, never from a developer's local working branch.

The mandatory Build Ticket

The Build Ticket is the formal dev-to-QA handover artifact. QA accepts a build for testing only when the Build Ticket is complete. It MUST contain:

  • What the build represents: a short description of the scope of this build.
  • Version: matching the release branch and JIRA Release version.
  • Fixes and additions: what is new, modified, or removed in this build.
  • Impact: the impact analysis of the change (components impacted, functional impact, technical impact).
  • Build location: the build URL (for an APK) or the deployment state and place (for a backend deploy to the QA environment), plus the exact branch it was created from.
  • Linked tickets: every ticket that was fixed or resolved by this build, attached to the Build Ticket.

Use the Build Ticket template.

flowchart TD
    A[Dev declares release complete] --> B[Freeze release branch]
    B --> C{Platform?}
    C -->|Mobile| D[Produce APK from release branch]
    C -->|Backend| E[Deploy release branch to QA environment]
    D --> F[Create Build Ticket]
    E --> F
    F --> G[Fill: scope, version, fixes/adds, impact, build URL/location, source branch]
    G --> H[Link all resolved tickets to Build Ticket]
    H --> I{Build Ticket complete?}
    I -->|no| G
    I -->|yes| J[QA accepts build for testing]
    J --> K[QA & Testing phase]

Example

Dev finishes release/v1.4.0. The branch is frozen. DevOps deploys it to the QA backend environment and the mobile build pipeline produces app-v1.4.0.apk. The lead creates Build Ticket BUILD-58: scope ("CSV export, payments retry fix, settings redesign"), version v1.4.0, the list of additions and fixes, the impact analysis, the QA environment URL plus the APK download link, the source branch release/v1.4.0, and links to the eight tickets resolved in this build. Only then does QA pick it up.