Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Environments #2352

Closed
dcramer opened this issue Nov 23, 2015 · 4 comments
Closed

Implement Environments #2352

dcramer opened this issue Nov 23, 2015 · 4 comments

Comments

@dcramer
Copy link
Member

dcramer commented Nov 23, 2015

A few goals here:

  • Work towards removal of one-project-per-env
  • Ensure we can clearly answer:
    • is this happening in prod?
    • whats happening in prod?
    • is this happening on the latest release in prod?

We'll need to tweak some things to make environments actually useful:

  • Add environment to current SDK
  • A release should technically be bound to an environment.
  • Artifacts are bound to a version, that is they are shared across all environments for the same version.
  • Many breakdowns would be more useful if they were broken up by the environment. Possibly breaking them up by the release (assuming release was bound to an env) is good enough.

Assuming the above, implementing environments will likely end up requiring a bunch of changes to release. We already know we need some of these in areas where a release gets staged, and making the stages simply be env bound might be enough. Most likely ew can do the following:

  • Add ReleaseEnvironment which would include release, environment, start/finish, and possibly things like the machines deployed. Alternatively the machine-type data, since its not useful in the short term, could just become a completely different object in the future.
  • Accept environment in the SDK (capable as of 4764331)
  • Auto-tag environments
@dcramer
Copy link
Member Author

dcramer commented Nov 23, 2015

@getsentry/team thoughts?

@dcramer
Copy link
Member Author

dcramer commented Nov 23, 2015

I want to get at least basic SDK changes in for 8.0. We're probably ok with the changes already present, but should give it some more thought to make sure SDKs and integrations can support the new flow without yet another big version after 8.0.

@dcramer dcramer added this to the 8.0 Release milestone Nov 23, 2015
@dcramer dcramer self-assigned this Nov 23, 2015
@dcramer
Copy link
Member Author

dcramer commented Nov 23, 2015

Rate limits

Right now people use multiple projects to work around rate limits, and in some situations even use multiple orgs. We are ignoring any limitations around how Sentry does billing as that will change in the future.

Tag Distribution

A lot of times you really only care about tags (or other data) in association with an environment. For example, you'd want to know that the server its happening on is also associated with production. I think it's unlikely you share things like servers, so that's probably not a great example, but browser might be. This also comes up for releases, so if we bind the release tagging to version+env and eventually do dimensions we can hit two birds with one stone.

@dcramer dcramer removed this from the 8.0 Release milestone Dec 3, 2015
@benvinegar
Copy link
Contributor

I believe most of what is described here has been implemented / shipped. Closing.

@github-actions github-actions bot locked and limited conversation to collaborators Dec 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants