Ship a release

Before you start Open the Releases module and know the version you're cutting (for example 2.1.0).

1. Create a release and give it a version and description.
2. Include the work it covers — requirements, architecture, tests, and risks — and attach the test plan that verifies it.
3. Add the documents and any external dependencies the release relies on.
4. Attach a Compliance Profile if the release must meet a specific framework.

Result A release that gathers everything in scope in one place, ready to baseline and assess.

1. Create the baselines that freeze the release's contents at this point — give each a Baseline Name.
2. Confirm the baseline snapshots capture the versions you intend to ship.

Result The release's contents are frozen as named snapshots, so what's approved is exactly what was reviewed — not whatever the items look like later.

1. Open the release Readiness view and review each Gate — coverage, test results, open risks, required approvals.
2. Work through each Blocker: close the gap, finish the verification, or resolve the open item it points to.
3. Re-check until the gates are green.

Result A release with no open blockers — demonstrably ready, against live data rather than a checklist someone filled in by hand.

Before you start All gates should be clear and the contents baselined.

1. Submit the release for approval. It moves through its signing chain.
2. Each approver reviews the evidence and signs with re-authentication, an approval meaning, and a reason — see Sign an approval.
3. When the chain completes, the release reaches its released state.

Result A signed, baselined release whose approval is bound to the exact evidence that existed at sign-off — an auditable record of what shipped and who attested to it.