Improve feature flag discoverability through change management
The problem
Feature flags are currently reported on in several places discoverable by infrastructure:
- Logs
- The feature-flag-log issue tracker
However, it's not easy to go from there, to a feature flag issue that could have been created in several places depending on the project. The feature flag issues that are created based on the template contain a lot of checkboxes that aren't always relevant, and therefore not always used. This makes it hard for people to discover what was changed when, and what impact it could have had.
Proposal
Generate feature-flag issues as change issues in the production issue tracker. We could use woodhouse to generate an appropriate issue, asking for relevant information to the engineer planning the feature flag rollout:
- feature flag name
- short description about what the feature flag does
- merge request that introduces the feature flag
- Criticality (default C4)
This would create a new change issue in the production issue tracker that is in a place that makes it easier to find for SREs during incidents.
Since this issue is linked from source code, chatops can also find the issue every time a flag is changed to add the change to the event log in the change description. Making sure that this information is always correct without engineers having to remember about updating the issue.