Releases & Health
A release is a version of your code that is deployed to an environment. When you give Sentry information about your releases, you can:
- Determine issues and regressions introduced in a new release
- Predict which commit caused an issue and who is likely responsible
- Resolve issues by including the issue number in your commit message
- Receive email notifications when your code gets deployed
Include a release ID (often called a "version") when you configure your client SDK.
The release name cannot:
- contain newlines, tabulator characters, forward slashes(
/) or back slashes(
- be (in their entirety) period (
.), double period (
..), or space (
- exceed 200 characters
The value can be arbitrary, but we recommend either of these naming strategies:
- Semantic Versioning:
packageis the unique identifier of the project/app (
versionis the semver-like structure
buildis the number that identifies an iteration of your app (
- Commit SHA: If you use a DVCS, we recommend using the identifying hash (for example, the commit SHA,
da39a3ee5e6b4b0d3255bfef95601890afd80709). You can let Sentry CLI automatically determine this hash for supported version control systems with
sentry-cli releases propose-version.
Releases are global per organization; prefix them with something project-specific for easy differentiation.
using Sentry; // Add this to the SDK initialization callback options.Release = "email@example.com";
The SDK attempts to locate the release to add to events sent to Sentry.
The SDK will first look at the entry assembly's
AssemblyInformationalVersionAttribute, which accepts a string as
value and is often used to set a GIT commit hash.
If that returns null, it'll look at the default
AssemblyVersionAttribute which accepts the numeric version number. When creating a project with Visual Studio, the value is set to 18.104.22.168.
Since that usually means that the version is either not being set, or is set via a different method. The automatic version detection will disregard this value and no Release will be reported automatically.
How you make the version available to your code is up to you. For example, you could use an environment variable that is set during the build process.
This tags each event with the release value. We recommend that you tell Sentry about a new release before deploying it, as this will unlock a few more features as discussed in our documentation about releases. But if you don’t, Sentry will automatically create a release entity in the system the first time it sees an event with that release ID.
After configuring your SDK, you can install a repository integration or manually supply Sentry with your own commit metadata. Read our documentation about setting up releases for further information about integrations, associating commits, and telling Sentry when deploying releases.
Monitor the health of releases by observing user adoption, usage of the application, percentage of crashes, and session data. Release health will provide insight into the impact of crashes and bugs as it relates to user experience, and reveal trends with each new issue through the release details, graphs, and filters.
The SDK will automatically manage the start and end of the sessions when the SDK is initialized.
We mark the session as:
- Errored: if the SDK captures an event that contains an exception (this includes manually captured errors).
By default, the .NET SDK is creating a session on application startup and end it on shut down. To disable sending sessions, set the
AutoSessionTracking flag to
using Sentry; // Add this to the SDK initialization callback options.AutoSessionTracking = false; // default: true