Difference between deploy and release?

[jeengbe]

Core or SDK?

Core Sentry product

Which part? Which one?

n/a

Description

There are references to both deploys and releases all throughout the documentation.
On Release Management, we find: "You can also associate deploys with releases.". How does a deploy relate to a release?

Let's say, I use git flow:

I deploy the latest development to staging and main to production. When do I create releases/deploys in which pipeline?

Suggested Solution

I'd guess that releases are, as in the image above, versioned deployments of the project. v0.1, v0.2 etc. are releases. Deploys, in turn, are instances of that release in an environment; I have one deploy per release in production. Which other deploys would I have? The documentation mentions staging, that, however, using a completely different versioning scheme (commit sha). Would I have separate releases for production (vX.Y) and staging (sha) with each only a single deploy? If so, that separation of release/deploy seems unnecessary.

Is that separation a feature in which the main branch is deployed to different environments? Which scenarios would that be?

Thanks a lot for an answer in advance! :)

[getsantry]

Assigning to @getsentry/support for routing, due by Wednesday, February 15th at 13:08 (yyz). ⏲️

[getsantry]

Routing to @getsentry/visibility for triage, due by Thursday, February 16th at 14:41 (yyz). ⏲️

[mjq-sentry]

How does a deploy relate to a release?

When you create a deploy with sentry-cli:

sentry-cli releases deploys "$VERSION" new -e ENVIRONMENT

the $VERSION given is the version used to identify the release, and the deployment will then be associated with that release.

I'd guess that releases are, as in the image above, versioned deployments of the project. v0.1, v0.2 etc. are releases. Deploys, in turn, are instances of that release in an environment; I have one deploy per release in production. Which other deploys would I have? The documentation mentions staging, that, however, using a completely different versioning scheme (commit sha). Would I have separate releases for production (vX.Y) and staging (sha) with each only a single deploy? If so, that separation of release/deploy seems unnecessary.

This depends on your own workflow. Typically, using the same release identifier for staging and production is probably going to make things easier, since it lets you compare data in the two environments and validate a particular build before releasing it. That release identifier could be a commit SHA or version number, whichever is more comfortable for your workflow. (If it helps, internally we use commit SHAs for both staging and production.) As a result, releases and deploys typically have a one-to-many relationship. If your workflow calls for it it could be one-to-one and take an extra CLI call, but having that be two separate CLI commands gives us flexibility for the more typical case.

Hope that helps!

[jeengbe]

Hi @mjq-sentry,

that does explain it, thanks a lot for the extensive answer! :)

Maybe you can add a link to your answer somewhere in the docs, as it is exactly what I was looking for when I checked there.

[jeengbe]

Hey @mjq-sentry, coming back with another question:

What's the point of registering deploys, is there a way to link events to deploys by environment/tags? The only effect I can see thus far is the list of deploys in the release overview, and the projects overview page. Am I missing something?