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)

1. Add a new table work_item_progresses
2. Introduce a new widget WorkItems::Widgets::Progress - EE only widget
3. 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

1. 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)

2. 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

3. 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

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

1. Run bundle exec rails db:migrate
2. Enable okrs_mvc feature flag for a project Feature.enable(:okrs_mvc, Project.find(6)
3. Create an Objective from Issues List(Use New Issue dropdown) and copy the id of it
4. 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}
5. 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.