Introduce progress widget for work items
What does this MR do and why?
Add progress widget for work_items - gitlab-org/incubation-engineering/okr/meta#5 (closed)
- Add a new table
work_item_progresses
- Introduce a new widget
WorkItems::Widgets::Progress
- EE only widget - Include progress widget in GraphQL
WorkItem
query,
Migration
bundle exec rails db:migrate
main: == 20221121091238 AddWorkItemProgress: migrating ==============================
main: -- create_table(:work_item_progresses, {})
main: -> 0.0050s
main: == 20221121091238 AddWorkItemProgress: migrated (0.0055s) =====================
ci: == 20221121091238 AddWorkItemProgress: migrating ==============================
ci: -- create_table(:work_item_progresses, {})
ci: -> 0.0047s
ci: == 20221121091238 AddWorkItemProgress: migrated (0.0048s) =====================
bundle exec rails db:rollback:main
main: == 20221121091238 AddWorkItemProgress: reverting ==============================
main: -- drop_table(:work_item_progresses)
main: -> 0.0020s
main: == 20221121091238 AddWorkItemProgress: reverted (0.0025s) =====================
Questions
-
What is the anticipated growth for the new table over the next 3 months, 6 months, 1 year? What assumptions are these based on?
- 3 months - ~10k rows
- 6 months - ~30k rows
- 1 year - ~100k rows
-
Assumptions
- Every employee in an organisation has an average of 5 OKRs(each OKR has one progress record)
-
How many reads and writes per hour would you expect this table to have in 3 months, 6 months, 1 year? Under what circumstances are rows updated? What assumptions are these based on?
- 3 months - 2k reads and 300 writes per hour
- 6 months - 6k reads and 1k writes per hour
- 1 year - 15k reads and 2.5k writes per hour
-
When does the row update?
- When user updates the progress of an OKR from UI
- When any of the child OKR progress is updated by user from UI, all the parent Objectives progress will be updated.
-
Assumptions
- Write happens typically once a week per OKR but post implementation of roll up logic every KR update typically triggers 5 more updates.
- 10,000 * 5 / (7 * 24) = ~300 writes per hour
- Read happens when a user goes to OKR page but the child items progress will also be rendered so for each visit to OKR page we can expect 10 additional reads.
- On average users visit OKR page thrice a week
- 10000 * 10 * 3 / (7 * 24) = ~2k reads per hour
- Write happens typically once a week per OKR but post implementation of roll up logic every KR update typically triggers 5 more updates.
-
Based on the anticipated data volume and access patterns,
- Does the new table pose an availability risk to GitLab.com or self-managed instances?
- I don't think so
- Does the proposed design scale to support the needs of GitLab.com and self-managed customers?
- YES
- Does the new table pose an availability risk to GitLab.com or self-managed instances?
SQL query to fetch progress
select * from work_item_progresses where issue_id = <issue_id>;
gitlabhq_development=# EXPLAIN select * from work_item_progresses where issue_id = 535;
QUERY PLAN
-------------------------------------------------------------------------------------------------------
Index Scan using work_item_progresses_pkey on work_item_progresses (cost=0.15..2.17 rows=1 width=26)
Index Cond: (issue_id = 535)
(2 rows)
GraphQL Query
{
workItem(id: "gid://gitlab/WorkItem/533") {
id,
workItemType {
id,
name
},
widgets {
type
... on WorkItemWidgetProgress {
progress,
type
}
}
}
}
GraphQL Response
{
"data": {
"workItem": {
"id": "gid://gitlab/WorkItem/533",
"workItemType": {
"id": "gid://gitlab/WorkItems::Type/2273",
"name": "Objective"
},
"widgets": [
{
"type": "PROGRESS",
"progress": 20
},
{
"type": "ASSIGNEES"
},
{
"type": "LABELS"
},
{
"type": "DESCRIPTION"
},
{
"type": "HIERARCHY"
},
{
"type": "MILESTONE"
}
]
}
}
}
|
How to set up and validate locally
- Run
bundle exec rails db:migrate
- Enable
okrs_mvc
feature flag for a projectFeature.enable(:okrs_mvc, Project.find(6)
- Create an Objective from Issues List(Use
New Issue
dropdown) and copy the id of it - From rails console create a progress record for the objective you have created above
WorkItems::Progress.create(progress: 20, issue_id: {replace with objective id}
- Go to GraphQl explorer and paste the query listed above and you should progress value in the response
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Abhilash Kotte