Releases and environemnts

I’m coming from a different system, Airbrake, so forgive me if these concepts don’t carry over to Sentry.

We’ve currently got Release Tracking set-up to handle POST requests from our Jenkins builds. We’re also declaring the environment in our log4j configuration to be the specific instance/server name.

I’m curious how these two concepts are relating. In our old system releases were scoped to a particular environment so a release to one environment would effectively reset the errors to that Environment.

In Sentry, I’m not seeing how Releases relate to Environments. How do you know which Environment your Release is going to? Does it assume all of them? Does it even matter with the way you handle Release Tracking?

Thanks!

1 Like

Also, if I’m deploying branches, should I be using the branch name in my release tracking info for the “version” parameter given that the contents of a branch can change? If I do multiple releases that have different "ref"s but the same “version” (the branch name) will the system somehow differentiate those or treat them as effectively the same release?

I think the Airbrake concepts are not carying over cleanly if I read this correctly.

I assume we are talking about a single project in an organisation in Sentry that is using release tracking and you defining an environment.

In Sentry an environment is just a tag which an event can have, you can filter on it but it is not seperated by default (so all environments are in a single event list and events combined if they occur in multiple environments).

Events get attached to the release they are first seen in. You will need to set them to resolved or “resolved in next release” by clicking the button in the UI. If an event regresses and reoccurs the event is assigned to a new release as an regression and needs to be resolved or “resolved in next release” again. They will not close automatically as soon as a release is sent to Sentry.

You can however let Sentry automatically mark the issue as resolved after it did not occur x days which you can configure in the project settings.

Let me know if I (or anyone) needs to clarify some more :slight_smile:

That makes sense thanks.

  • Is it assumed that all releases go out to all environments? If an issue comes up in one environment, what guarantees that a particular release is running there? I think this might be the diff between Sentry and Airbrake. Airbrake tracks deploys/releases per environment.
  • Also what about my question here:

if I’m deploying branches, should I be using the branch name in my release tracking info for the “version” parameter given that the contents of a branch can change? If I do multiple releases that have different "ref"s but the same “version” (the branch name) will the system somehow differentiate those or treat them as effectively the same release?

Yes this is true and is something I am myself working around by using multiple projects. I currently have a “team” for my app and a “project” for production and a different one for “staging”.

So you are correct, releases are only tracked by a point in time and nothing else AFAIK (this would be a stellar addition though so it might be worth checking if there is a GitHub and issue and if not create it).

For our staging environment we deploy every single commit and use the commit hash as the version. So you could do that too, I think if you would use the branch in combination with a ref you are unable to use that “version” again since the ref is only sugar and the version is what is actually used.

1 Like