This PR introduces a set of features that were in a way dependent on each other which makes it quite large when compared to a typical PR.
Automated Backstage integration setup for mapped entities: With the goal of simplifying the setup process for mapped entities we introduced a feature that automatically creates a integration on the corresponding PagerDuty service when a pagerduty.com/service-id property is available.
With this feature, admins can skip the step of creating an integration in PagerDuty and copy the integration key to each Backstage entity file. They can now simply add the pagerduty.com/service-id annotation to their service, or simply use the PagerDutyPage to map existing PagerDuty services to Backstage entities and the plugin will take care of the rest. This change is related to #80.
Plugin configuration persistence layer: To support two-way sync for service dependencies we decided to give the admins the option of choosing which is their main source of truth and for that reason we introduced a new section in PagerDutyPage where you can specify your preferences. The backend centralises all the persistence layer and this PR includes all the necessary methods for it.
Two-way service dependency sync: This PR introduces a way to keep your service dependencies in sync between PagerDuty and Backstage. Admins will be able to choose which source is the main one (Backstage, PagerDuty, or both). This is an opt-in feature that you can enable on the PagerDutyPage under the configuration tab.
Issue number:#111 from @pagerduty/backstage-plugin
Type of change
[x] New feature (non-breaking change which adds functionality)
[ ] Fix (non-breaking change which fixes an issue)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
Description
This PR introduces a set of features that were in a way dependent on each other which makes it quite large when compared to a typical PR.
Automated Backstage integration setup for mapped entities: With the goal of simplifying the setup process for mapped entities we introduced a feature that automatically creates a integration on the corresponding PagerDuty service when a
pagerduty.com/service-id
property is available.With this feature, admins can skip the step of creating an integration in PagerDuty and copy the integration key to each Backstage entity file. They can now simply add the
pagerduty.com/service-id
annotation to their service, or simply use thePagerDutyPage
to map existing PagerDuty services to Backstage entities and the plugin will take care of the rest. This change is related to #80.Plugin configuration persistence layer: To support two-way sync for service dependencies we decided to give the admins the option of choosing which is their main source of truth and for that reason we introduced a new section in
PagerDutyPage
where you can specify your preferences. The backend centralises all the persistence layer and this PR includes all the necessary methods for it.Two-way service dependency sync: This PR introduces a way to keep your service dependencies in sync between PagerDuty and Backstage. Admins will be able to choose which source is the main one (Backstage, PagerDuty, or both). This is an opt-in feature that you can enable on the
PagerDutyPage
under theconfiguration
tab.Issue number: #111 from @pagerduty/backstage-plugin
Type of change
Checklist
If this is a breaking change 👇
Acknowledgement
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.