You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Terraform provider covers a good portion of project provisioning: teams,
projects, alert rules. Organizations with many projects and a platform team that
owns the standard still fall back to the UI for the settings that matter most to
consistency, and there is no concept of a baseline that projects inherit from.
Specific gaps:
Grouping and fingerprinting rules are configured per project in the UI. For teams
where fingerprinting is the difference between usable and unusable grouping, this
is the single most valuable thing to standardise and the one that cannot be.
Issue-tracker integration configuration, including status mappings, is not
manageable as code, so every project's workflow integration is set up by hand.
There is no organization-level template. New projects start from defaults rather
than from the organization's standard, which means every project begins
misconfigured relative to what the platform team intends.
There is no drift view. Nothing shows which projects have diverged from the
standard, or in what way, so the standard erodes silently.
There is a real tension underneath this and both halves need support: an
organization wants a consistent baseline, and individual teams need to tune specific
settings for their own product. Today neither is well served, because without a
baseline there is nothing to inherit from and nothing to deliberately diverge from.
Organization-level project templates that new projects inherit at creation, with
explicit per-project overrides so local tuning is supported and visible rather
than indistinguishable from drift.
A drift view showing which projects differ from their template and where.
Problem Statement
The Terraform provider covers a good portion of project provisioning: teams,
projects, alert rules. Organizations with many projects and a platform team that
owns the standard still fall back to the UI for the settings that matter most to
consistency, and there is no concept of a baseline that projects inherit from.
Specific gaps:
where fingerprinting is the difference between usable and unusable grouping, this
is the single most valuable thing to standardise and the one that cannot be.
manageable as code, so every project's workflow integration is set up by hand.
than from the organization's standard, which means every project begins
misconfigured relative to what the platform team intends.
standard, or in what way, so the standard erodes silently.
There is a real tension underneath this and both halves need support: an
organization wants a consistent baseline, and individual teams need to tune specific
settings for their own product. Today neither is well served, because without a
baseline there is nothing to inherit from and nothing to deliberately diverge from.
Solution Brainstorm
to integration status mappings, following the pattern of Add public API and Terraform support for CODEOWNERS import #116573.
explicit per-project overrides so local tuning is supported and visible rather
than indistinguishable from drift.
Related: #116573
Product Area
Settings - General
Requested by Saad Khan.
--
View Junior Session [Sentry]