Skip to main content

Review release readiness

Use this workflow before promoting a release to production.

1. Create or update the release​

tiden release create \
  --product-id <product-id> \
  --version "$RELEASE_VERSION" \
  --environment staging \
  --build-sha "$(git rev-parse HEAD)" \
  --url "$BUILD_URL"

With --build-sha, the release's gate is computed from the test results of that commit only (see Release captures).

2. Confirm telemetry uses the same release​

Your runtime SDK should use the same release value:

Tiden.init({
  dsn: process.env.TIDEN_DSN,
  release: process.env.RELEASE_VERSION,
  environment: 'staging',
})

3. Review open issues​

Open the release detail or Issues page and filter by release/environment. Resolve or ignore issues only after triage.

4. Check traceability​

Open Traceability for main or the release context. Look for:

  • no_test specs.
  • not_run specs.
  • Failing test cases.
  • Components with weak coverage.

5. Run the quality gate​

tiden gate check --product-id <product-id> --release <release-id>

If the command reports the gate as pending, the commit's test runs have not finished reporting yet; it exits with code 3 until they do.

If blocked:

  1. Open the gate page.
  2. Expand the blocking component.
  3. Follow fix hints.
  4. Fixes land on a new commit, so gate that commit: announce a new release for it, or point this release at it with tiden release capture <release-id> --build-sha <new-sha>. Capturing without --build-sha reads the release's own commit again and does not see the fixes.

6. Document risk acceptance​

Accept risk on the branch, before it merges: a release's captured verdict cannot be risk-accepted afterwards. Include a clear reason and approver. Do not use risk acceptance for unknown failures or untriaged production issues.