Release Readiness Dashboard
Rules for Scoring
Looking back at groups of queries, we know that each individual group is a metric that the Release Management team cares about when deciding on the release readiness of that particular version. One of the key objectives of the dashboard is being able to automatically compute a release readiness score based on important metrics. In the screenshot above, we notice that two of the groups have titles with colored backgrounds (green), indicating the status of that group.
Statuses of each group on the dashboard are denoted by 3 primary colors of
red. To automatically determine the status of individual groups, computational rules must be scripted. In a future implementation, individual group statuses in each version will also be able to be aggregated for computing an overall release readiness score for the particular version.
js file as shown in the specified directory. Scripting can begin immediately after that, with inline comments available to provide guidance if necessary. Note that if a user scripting a rule does not have deployment rights, the stack owner must be contacted at the end to upload the script file.
In the background, every time a version view is loaded the server checks for the existence of
/assets/rules/rule_[group_id].js for each group that will be loaded. If found, the script file is loaded on the view and executed when data is returned from the Elastic Search cluster that mirrors Bugzilla. The resulting status color from executing the rule is then applied to its corresponding groups’ title. Using an architecture like that, we reap the benefits of:
- Scripting of rules enabled for both default and custom groups.
- Flexible scripting for defining rules with any level of complexity.
- Upload into
/assets/rules/rule_[group_id].jsif group has rule, delete the file otherwise. i.e. scripting rules for a group is optional.
- Anyone is free to access the boilerplate and start scripting a rule, but only the stack owner has deployment rights.