Workflow: release tracking from CI to triage

# Workflow: release tracking from CI to triage

A release in Sentry ties errors to the deploy that introduced them. Without it, every issue is timeless; with it, triage starts with "which release?" and often ends there.

## 1. Create the release in CI

Every production deploy runs:

```
sentry-cli releases new "[service]@[version]"
sentry-cli releases set-commits "[service]@[version]" --auto
sentry-cli releases finalize "[service]@[version]"
```

`--auto` associates the commits since the previous release. Finalize after the deploy succeeds, so a rolled-back deploy never looks like the current release.

## 2. Match the SDK's release string

The SDK's `release` option must equal the CLI's release name exactly. Derive both from the same CI variable. A mismatch means errors land on a phantom release with no commits and no artifacts.

## 3. Ship artifacts with the release

Upload source maps (or debug files for native) against the same release before finalizing. The release page becomes one place with commits, artifacts, and the errors they produced.

## 4. Triage with the release view

When a new issue appears after a deploy:

1. Open the issue's release. The suspect commits are right there.
2. The commit author is the first person to loop in, before broadcast triage.
3. Check release health: crash-free rate and adoption tell you whether this is one unlucky user or a bad rollout.
4. If it is a bad rollout, the release view shows exactly which deploy to roll back.

## 5. Alert on new issues per release

An alert rule for "new issue in the latest release" routes fresh breakage to the deploying team immediately, while they still remember what they shipped.

## Verify

Pick the last three production deploys: each has a release page with commits, artifacts, and linked issues. The on-call engineer can name the suspect commit for the latest issue without opening the repo.