Work items development

  • Work item 목록은 그룹 레벨에서만 사용할 수 있습니다. http://gdk.test:3000/groups/flightjs/-/work_items는 기능 플래그 namespace_level_work_items를 활성화해야 합니다.
  • 새로운 work item UI는 프로젝트 레벨에서 사용할 수 있습니다. work_items_alpha 기능 플래그를 활성화한 후 http://gdk.test:3000/flightjs/Flight/-/work_items/new에서 확인할 수 있습니다.
  • work item 보기/편집 UI는 프로젝트 레벨에서 사용할 수 있습니다. work_items_alpha 기능 플래그를 활성화한 후 http://gdk.test:3000/flightjs/Flight/-/work_items/:iid에서 확인할 수 있습니다.

기능 플래그에 대한 더 자세한 내용은 epic 11777에서 확인할 수 있습니다.

도전 과제

이슈는 협업을 위한 중앙 집중식 허브가 될 수 있는 잠재력을 가지고 있습니다. 다양한 작업 유형에 따라 다양한 필드와 다른 컨텍스트가 필요한 점을 인정해야 합니다. 예를 들어:

  • 버그는 재현할 수 있는 단계를 나열해야 합니다.
  • 인시던트는 해당 인시던트에만 관련된 스택 추적 및 기타 맥락 정보가 필요합니다.

각 객체 유형이 별도 모델로 발전하는 대신, 포함하는 위젯(하나 이상의 속성)을 사용자화할 수 있는 기본 공통 모델을 표준화할 수 있습니다.

현재 이슈 사용에 관한 몇 가지 문제점은 다음과 같습니다:

  • 이슈 유형을 표시하기 위해 레이블을 사용하면 보고 보기가 복잡해집니다.
  • 이슈 유형은 레이블 사용의 주요 두 가지 사용 사례 중 하나이므로 해당 유형에 대한 최우선 지원을 제공하는 것이 타당합니다.

  • 이슈에 더 많은 기능을 추가함에 따라 이슈가 혼잡해지고 완벽하지 않습니다:

    • 다른 객체와의 관계를 표면화할 일관된 패턴이 없습니다.
    • 레이블을 사용하기 때문에 서로 다른 유형의 이슈에 대한 일관된 상호 작용 모델이 없습니다.
    • 이슈 유형의 다양한 구현은 유연성과 확장성이 부족합니다.
  • 에픽, 이슈, 요구 사항 등은 유사하지만 세세한 차이로 사용자는 각 객체의 복잡한 작동 모델을 이해해야 합니다.
  • 이슈가 지원해야 할 새로운 작업들에 대한 확장성이 부족합니다.
  • 이슈 유형의 핵심 역할인 이슈 추적을 넘어서 다른 work item 유형과 로직 및 구조적 차이를 지원하기 위해 이슈 유형을 키우면 코드베이스 유지보수와 기능 개발이 더 큰 도전이 됩니다.
  • 새로운 기능은 일반적으로 이슈에서 행동을 가져오는 일등 객체로 구현됩니다. 이는 중복된 노력으로 이어지고 결국 일반적 상호 작용 사이에 작은 차이가 발생합니다. 따라서 일관성 없는 사용자 경험으로 이어질 수 있습니다.

Work Item 용어

혼란을 피하고 효율적인 커뮤니케이션을 보장하기 위해 Work Item에 대해 논의할 때는 오직 다음 용어만 사용할 것입니다. 이 목록은 Work Item 용어에 대한 단일 정보 원천(SSoT)입니다.

용어 설명 잘못된 사용 예 올바른 사용 예
work item type Work Item의 클래스; 예: 이슈, 요구 사항, 테스트 케이스, 인시던트, 또는 작업 에픽은 최종적으로 이슈가 될 것입니다 에픽은 최종적으로 work item type이 될 것입니다
work item Work Item의 인스턴스    
work item view Work Item의 새로운 프론트엔드 뷰 이것은 새로운 뷰에서 렌더링되어야 합니다 이것은 Work Item 뷰에서 렌더링되어야 합니다
legacy object Work Item 유형에 변환된 또는 변환될 객체 에픽은 독립/이전/기존 객체에서 work item type으로 이전될 것입니다 에픽은 상속된 객체에서 Work Item 유형으로 변환될 것입니다
legacy issue view 이슈 및 인시던트를 렌더링하는 기존 뷰 이슈는 이전 뷰에서 계속 렌더링됩니다 이슈는 이전 이슈 뷰에서 계속 렌더링됩니다
issue 기존 이슈 모델    
issuable issuable 모듈을 현재 사용하는 모든 모델 (이슈, 에픽 및 MR) 인시던트는 issuable이다 인시던트는 work item type이다
widget 특정 작업 항목 데이터를 표시하거나 상호 작용할 수 있는 UI 요소    

과거에 사용된 일부 용어는 혼란스러워졌으며 지금은 권장되지 않습니다.

용어 설명 잘못된 사용 예 올바른 사용 예
issue type Work Item 클래스를 참조하는 과거의 방식 작업은 이슈 유형이다 작업은 work item type이다

마이그레이션 전략

WI 모델은 기존 Issue 모델을 기반으로 구축될 것이며, Issue 모델 코드를 WI 모델로 점진적으로 마이그레이션할 것입니다.

접근 방식 중 하나는 다음과 같습니다: 

class WorkItems::WorkItem < ApplicationRecord
  self.table_name = 'issues'

  # ... 현재 issue.rb 코드 전체
end

class Issue < WorkItems::WorkItem
  # 이 클래스에 코드를 추가하지 말고 WorkItems:WorkItem에 추가하세요
end

우리는 이미 issue 테이블 내에서 issue_type 열을 통해 WITs의 개념을 사용하고 있습니다. issue, incident, 그리고 test_case issue types이 있습니다. 이를 확장하여 향후 사용자가 사용자 정의 WITs를 정의할 수 있도록 하기 위해 issue_type을 work_item_types 테이블로 이동할 것입니다. issue_type을 work_item_types로의 마이그레이션 과정은 이슈의 프로젝트 루트 그룹에 대한 모든 WITs 세트를 이 이픽에서 설명한 대로 작성할 것입니다.

참고: 먼저 WIT을 루트 레벨 그룹에서만 정의할 수 있으며, 이후 하위 그룹에서 상속될 것입니다. 후속 반복에서 하위 그룹에서 새 WIT를 정의할 수 있는 가능성을 조사할 것입니다.

work_item_types 테이블 소개

예를 들어, ID가 11, 12, 13인 세 개의 루트 레벨 그룹이 있다고 가정하고 다음과 같은 기본 유형이 있다고 가정해보겠습니다: issue: 0, incident: 1, test_case: 2.

해당하는 work_item_types 레코드:

namespace_id base_type title
11 0 Issue
11 1 Incident
11 2 Test Case
12 0 Issue
12 1 Incident
12 2 Test Case
13 0 Issue
13 1 Incident
13 2 Test Case

이를 실현하기 위해 우리가 할 일:

  1. issues 테이블에 work_item_type_id 열을 추가합니다.
  2. 새로운 또는 업데이트된 이슈에 대해 issues#issue_type 및 issues#work_item_type_id 열에 동시에 쓰도록 합니다.

  3. work_item_type_id 열에 issue의 프로젝트 루트 그룹에 해당하는 work_item_types#id를 가리킬 수 있도록 backfill을 할 것입니다. 예를 들어: 

    issue.project.root_group.work_item_types.where(base_type: issue.issue_type).first.id.
  4. issues#work_item_type_id가 채워지면, issue_type 대신 work_item_type_id를 사용하여 쿼리를 전환할 수 있습니다.

새 WIT를 도입하는 데는 두 가지 옵션이 있습니다:

  • 위 과정의 첫 번째 단계를 따를 것입니다. 사용자가 새 WIT를 사용할 수 있도록 하기 위해 루트 레벨 그룹에 대한 새 WIT를 추가하는 마이그레이션을 실행해야 할 것입니다. 긴 실행 시간이 필요한 마이그레이션 외에도 work_item_types에 수백만 개의 레코드를 삽입해야 할 수 있습니다. 이는 사용자에게 불필요한 WIT를 원하지 않는 사용자에게는 원치 않을 수 있습니다.
  • 사용자가 선택한 경우에만 work_item_types의 특정 루트 레벨 그룹에 대한 레코드가 생성될 수 있도록 선택 사항 흐름을 만들 것입니다. 그러나 이는 새로 도입된 work item type의 가시성이 낮아질 수 있음을 의미합니다.

업무 항목 유형 위젯

위젯은 업무 항목에서 존재할 수 있는 단일 구성 요소입니다. 이 구성 요소는 하나 이상의 업무 항목 유형에서 사용될 수 있으며 구현 단계에서 가볍게 사용자 정의할 수 있습니다.

위젯에는 전담 UI(있는 경우)와 위젯에서 사용하는 데이터를 표시하고 관리하는 관련 로직이 모두 포함되어 있습니다. 데이터 모델과 위젯 사이에는 일대다 연결이 있을 수 있습니다. 이는 동일한 데이터를 사용하거나 관리하는 여러 위젯이 있을 수 있으며 동시에(예: 읽기 전용 요약 위젯 및 편집 가능한 상세 위젯 또는 동일한 모델의 두 개의 필터링된 다른 보기를 보여주는 두 위젯) 존재할 수 있음을 의미합니다.

위젯은 목적에 따라 구별되어야 합니다. 가능한 경우, 이 목적은 최대한 추상화하여 재사용성을 극대화해야 합니다. 예를 들어, “작업”을 관리하는 위젯은 “하위 항목”으로 구축되었습니다. 하위 항목을 관리하는 대신 특정 타입의 하위 항목을 관리하기보다는 이것을 추상화하여 모든 하위 항목을 관리하도록 설계되었습니다.

모든 업무 항목 유형(WITs)은 미리 정의된 위젯 풀을 공유하며 특정 WIT에서 활성화되는 위젯에 따라 사용자 정의될 것입니다. 모든 속성(열 또는 연관성)은 해당하는 WIT와 무관하게 자체 캡슐화된 기능을 갖는 위젯이 될 것입니다. 따라서 어떤 WIT이든지 어떤 위젯이든 사용할 수 있기 때문에 특정 WIT에 대해 활성화된 위젯을 정의하기만 하면 됩니다. 따라서 특정 작업 항목 유형으로 전환하면 다른 일련의 위젯이 표시됩니다.

업무 항목 위젯 및 새로 만드는 방법에 대해 자세히 알아보세요.

위젯 메타데이터

각 WIT마다 해당 활성 위젯으로 사용자 정의하기 위해 WIT와 특정 위젯을 매핑하는 데이터 구조가 필요합니다.

WIT 유형이 GitLab에 의해 고객을 위한 다양한 작업 항목 계획을 구현하기 위해 매우 유연하게 구성될 것을 의도합니다(의견 기반 GitLab 워크플로, 또는 SAFe 5 등), 그리고 최종적으로는 고객이 자체 워크플로를 사용자 정의할 수 있도록 하려 합니다.

이 경우, 작업 항목 계획은 특정 특성(일부 위젯이 활성화된 상태나 아닌 상태), 예를 들어, Epic, Story, Bug, Task 등의 유형으로 정의될 것입니다.

새로운 작업 항목 아키텍처를 구축하는 동안 이러한 다양한 유형을 매우 유연한 방식으로 정의할 수 있도록 하려 합니다. 먼저 GitLab이 이 시스템을 소개한 후에(고객 사용자 정의를 도입하지 않는 상태에서) 초기 시스템을 더 잘 구축할 수 있습니다.

작업 항목의 base_type은 각 유형에 사용 가능한 위젯을 정의하는 데 사용됩니다(현재 상태). 이 정의는 데이터베이스 테이블에 저장되어야 합니다. WIT 위젯 메타데이터의 정확한 구조는 아직 정의되지 않았습니다. 데이터의 기본 유형은 다른 유형의 리소스(요구 사항 및 사건)을 작업 항목으로 변환하는 데 도움을 주고, 결국(이러한 리소스가 정규적인 작업 항목으로 변환될 때) base_type이 삭제될 것입니다.

WIT 위젯 아키텍처의 구조가 최종화되기 전에는 새로운 작업 항목 유형을 생성하지 않기로 결정했습니다. 새로운 작업 항목 유형이 절대적으로 필요한 경우에는 프로젝트 관리 엔지니어 팀 멤버에 문의하십시오.

데이터베이스에서 새로운 작업 항목 유형 생성

issue_type 열을 work_item_types 테이블을 사용하여 제거한 것을 마쳤습니다(이 에픽에 설명되어 있음).

work_item_types 테이블이 도입된 후에, work_item_types를 더 추가하고 다른 팀들이 쉽게 추가할 수 있도록 하려 합니다. 새로운 work_item_type을 도입하려면 다음을 수행해야 합니다:

  1. work_item_types 테이블에 새 레코드를 생성하는 데이터베이스 마이그레이션 작성.
  2. Gitlab::DatabaseImporters::WorkItems::BaseTypeImporter를 업데이트하기.

다음 MR은 새 work_item_types을 도입하는 방법을 보여줍니다:

데이터베이스 마이그레이션 작성

먼저, work_item_types 테이블에 새 레코드를 생성하는 데이터베이스 마이그레이션을 작성합니다.

마이그레이션 작성 시 다음 사항을 염두에 두십시오:

  • 중요: 기존 API에서 새 유형을 제외합니다.
    • 새로 생성된 이 유형이 기존 기능(예: 이슈 목록과 같은)에 표시되지 않도록 하려면, 아마도 새 유형을 이 제외 목록에 추가해야합니다. 이렇게 함으로써 마이그레이션이 실행되는 즉시 사용자가 새 유형으로 새 이슈 및 작업 항목을 생성할 수있는 경우를 제외하고(해당 마이그레이션이 있는 MR이 롤백되고 마이그레이션이 없는 경우도 실행된 경우를 생각할 때) 새 API에서 하나를 예상하지 않습니다.
  • 후속 MR이 작업 항목 생성을 기대할 수 있도록 일반 마이그레이션을 사용합니다.

    • 일반 마이그레이션을 사용하여 새 작업 항목 유형을 추가하는 것이 바람직할 것으로 생각됩니다. 이렇게 하면 새 유형을 추가하는 후속 MR은 즉시 존재하는 것으로 가정할 수 있으므로 다음 릴리스를 기다릴 필요가 없습니다.

      중요: 일반 마이그레이션을 사용하는 이유로 다음 사항을 확인해야합니다:

      1. 일반 마이그레이션의 시간 가이드라인을 초과하지 않도록 합니다.
      2. 마이그레이션이 역호환성을 유지하도록 해야합니다. 즉, 배포된 코드가 배포 롤백을하고 마이그레이션이 없는 경우에도 정상 작동해야합니다.
  • 마이그레이션은 실패하지 않아야 합니다.
    • work_item_types와 관련된 데이터는 새 유형을 생성하는 마이그레이션을 실행할 때 특정 상태에 있을 것으로 기대합니다. 현재 우리는 데이터 상태에 의지할 수있는 얼마나 많은 논의 중에 시드와 마이그레이션에 의해 데이터 상태에 의존할 수있는지에 대한 논의가 있습니다. 데이터가 일관성 없는 상태로 발견되더라도 마이그레이션을 실행하지 않고 실패하지 않기를 기대합니다. 이것을 변경하기 위해 몇 가지 데이터베이스 작업을 업데이트해야한다고 생각됩니다.
  • 새 유형에 대한 위젯 정의 추가.
    • 마이그레이션은 새로운 작업 항목에 필요한 위젯 정의와 함께 새 작업 항목 유형을 추가합니다. 선택하는 위젯은 새로운 작업 항목이 지원하는 기능에 따라 다르지만, “Description”과 같이 모든 새로운 작업 항목이 필요한 위젯이 있습니다.
  • 선택 사항. 계층 제한 생성.
    • 예시 MR 중 하나에서 work_item_hierarchy_restrictions 테이블에 레코드를 삽입합니다. 이것은 새로운 작업 항목 유형이 Hierarchy 위젯을 사용할 경우에만 필요합니다. 이 테이블에서는 어떤 작업 항목 유형이 어떤 유형의 하위 항목을 가질 수 있는지, 그리고 동일한 유형의 작업 항목의 계층 깊이를 지정해야합니다. 새 제한은 작업 항목 유형에 대해 캐시되기 때문에 연관된 작업 항목 유형에서 clear_reactive_cache!을 호출해야합니다.
  • 선택 사항. 연결된 항목 제한 생성.

    • Hierarchy 위젯과 유사하게, Linked items 위젯도 다른 유형과 링크될 수 있는 규칙을 지원합니다. 제한은 소스 유형이 다른 유형에 관련될 수 있는지, 또는 다른 유형을 차단할 수 있는지를 지정할 수 있습니다. 현재 제한 사항:

      유형 관련 가능 차단 가능 차단될 수 있음
      Epic Epic, issue, task, objective, key result Epic, issue, task, objective, key result Epic, issue, task
      Issue Epic, issue, task, objective, key result Epic, issue, task, objective, key result Epic, issue, task
      Task Epic, issue, task, objective, key result Epic, issue, task, objective, key result Epic, issue, task
      Objective Epic, issue, task, objective, key result Objective, key result Epic, issue, task, objective, key result
      Key result Epic, issue, task, objective, key result Objective, key result Epic, issue, task, objective, key result
  • 마이그레이션 스펙에 대해 공유 예시 사용.
    • 다양한 마이그레이션 유형(새 작업 항목 유형, 새 위젯 정의 등)에 사용할 공유 예시가 있으므로 이러한 공유 예시를 사용해야합니다. 변경 내용은 add_work_item_widget_shared_examples.rb에 있습니다. 
# 티켓 작업 항목 추가 예시

데이터베이스에 이미 `Ticket` 작업 항목 유형이 있지만, 이를 마이그레이션 예시로 사용할 것입니다.
새 유형의 경우 새 이름과 ENUM 값을 사용해야 함에 유의하십시오.

```ruby
class AddTicketWorkItemType < Gitlab::Database::Migration[2.1]
  disable_ddl_transaction!
  restrict_gitlab_migration gitlab_schema: :gitlab_main

  ISSUE_ENUM_VALUE = 0
  TICKET_ENUM_VALUE = 8
  TICKET_NAME = 'Ticket'

  TICKET_WIDGETS = {
    'Assignees' => 0,
    'Description' => 1,
    'Hierarchy' => 2,
    'Labels' => 3,
    'Milestone' => 4,
    'Notes' => 5,
    'Start and due date' => 6,
    'Health status' => 7,
    'Weight' => 8,
    'Iteration' => 9,
    'Notifications' => 14,
    'Current user todos' => 15,
    'Award emoji' => 16
  }.freeze

  class MigrationWorkItemType < MigrationRecord
    self.table_name = 'work_item_types'
  end

  class MigrationWidgetDefinition < MigrationRecord
    self.table_name = 'work_item_widget_definitions'
  end

  class MigrationHierarchyRestriction < MigrationRecord
    self.table_name = 'work_item_hierarchy_restrictions'
  end

  def up
    existing_ticket_work_item_type = MigrationWorkItemType.find_by(base_type: TICKET_ENUM_VALUE, namespace_id: nil)

    return say('티켓 작업 항목 레코드가 이미 존재하므로, 생성을 건너뜁니다.') if existing_ticket_work_item_type

    new_ticket_work_item_type = MigrationWorkItemType.create(
      name: TICKET_NAME,
      namespace_id: nil,
      base_type: TICKET_ENUM_VALUE,
      icon_name: 'issue-type-issue'
    )

    return say('티켓 작업 항목 레코드 생성에 실패했으므로, 생성을 건너뜁니다.') if new_ticket_work_item_type.new_record?

    widgets = TICKET_WIDGETS.map do |widget_name, widget_enum_value|
      {
        work_item_type_id: new_ticket_work_item_type.id,
        name: widget_name,
        widget_type: widget_enum_value
      }
    end

    MigrationWidgetDefinition.upsert_all(
      widgets,
      unique_by: :index_work_item_widget_definitions_on_default_witype_and_name
    )

    issue_type = MigrationWorkItemType.find_by(base_type: ISSUE_ENUM_VALUE, namespace_id: nil)
    return say('Issue 작업 항목 유형을 찾을 수 없어 계층 제약 조건 생성을 건너뜁니다.') unless issue_type

    # 새 유형이 `Hierarchy` 위젯을 사용하는 경우에만 이 마이그레이션이 필요합니다.
    restrictions = [
      { parent_type_id: new_ticket_work_item_type.id, child_type_id: new_ticket_work_item_type.id, maximum_depth: 1 },
      { parent_type_id: new_ticket_work_item_type.id, child_type_id: issue_type.id, maximum_depth: 1 }
    ]

    MigrationHierarchyRestriction.upsert_all(
      restrictions,
      unique_by: :index_work_item_hierarchy_restrictions_on_parent_and_child
    )
  end

  def down
    # 이미 이슈가 이 이슈 유형을 사용하고 있는 가능성이 있으므로,
    # 촘촘한 외래 제약조건으로 인해 어떤 데이터도 제거하려고 시도하지 않겠습니다.
  end
end

Gitlab::DatabaseImporters::WorkItems::BaseTypeImporter 업데이트

BaseTypeImporter를 통해 우리는 각 유형의 구조와 각 유형에 연관된 위젯을 명확하게 시각화할 수 있습니다. BaseTypeImporter는 신설된 GitLab 설치 및 테스트 스위트에 대한 단일 진실의 원천이어야 합니다. 이것은 항상 마이그레이션으로 변경하는 내용을 반영해야 합니다.

사용자 지정 작업 항목 유형들

WIT 위젯 메타데이터 및 WIT를 특정 위젯에 매핑하는 주변 작업을 통해 사용자에게 사용자 지정 WIT를 노출시킬 수 있게 될 것입니다. 사용자는 자체적으로 WIT를 생성하고 미리 정의된 풀에서 위젯을 사용자화할 수 있게 될 것입니다.

사용자 지정 위젯

최종적인 목표는 사용자에게 사용자 지정 위젯을 정의하고 이러한 사용자 지정 위젯을 모든 WIT에서 사용할 수 있게 하는 것입니다. 그러나 이것은 훨씬 더 나아진 이터레이션이며 데이터 및 애플리케이션 아키텍처를 결정하기 위해 추가 조사가 필요합니다.

요구 사항 및 이픽을 작업 항목 유형으로 마이그레이션

요구 사항과 이픽을 작업 항목 유형으로 마이그레이션하여 해당 작업 항목 유형의 고유한 위젯을 갖게 될 것입니다. 그를 위해 issues 테이블로 데이터를 마이그레이션하고 현재의 requirements 및 epics 테이블을 이전 참조를 보장하기 위한 프록시로 유지할 것입니다.

요구 사항을 작업 항목 유형으로 마이그레이션

현재 Requirement 속성은 주로 Issue 속성의 하위 집합이므로 마이그레이션은 주로 다음과 같습니다:

  • 데이터 마이그레이션.
  • API 수준에서 역호환성 유지.
  • 이전 참조가 계속 작동하도록 보장.

다른 기저 데이터 구조로의 마이그레이션은 최종 사용자에게는 원활해야 합니다.

이픽을 작업 항목 유형으로 마이그레이션

Epic에는 현재 Issue WIT에 없는 일부 추가 기능이 있습니다. 따라서 Epic을 작업 항목 유형으로 마이그레이션하려면 현재의 Epic 개체와 WIT 간의 기능 동등성을 제공해야 합니다.

주요 부족한 기능은 다음과 같습니다:

  • 그룹 수준의 작업 항목 가져오기. 이것은 그룹 및 프로젝트 통합 이니셔티브에 종속됩니다.
  • 계층 위젯: 작업 항목을 계층 구조로 구조화할 수 있는 능력.
  • 상속된 날짜 위젯.

이미 에픽을 사용 중인 사용자의 워크플로우를 방해하지 않기 위해, 우리는 프로젝트 수준에서 에픽과 유사한 기능을 제공할 Feature라는 새로운 WIT를 소개할 것입니다. 그것은 그룹 및 프로젝트 통합의 진행 상황과 결합됨으로써 에픽을 WIT로의 원활한 마이그레이션 경로를 사용자의 워크플로우에 거의 영향을 미치지 않게 제공할 수 있게 될 것입니다. ```

Work item, work item type, 및 위젯 로드맵

작업 항목, 작업 항목 유형 및 사용자 정의 위젯(CW)로 점진적인 접근 방식을 채택할 것입니다. 전방으로 진행될 작업의 대략적인 개요는 에픽 6033을 참조하세요.

Redis HLL Counter 스키마

Plan xMAU, Project Management xMAU, Certify xMAU 및 Product Planning xMAU를 고려한 보다 확장 가능한 Redis 카운터 스키마가 필요합니다. 현재의 Redis 슬롯 스키마로는 그룹 내 또는 단계 수준에서 기능 간 이벤트를 집계하고 중복 처리할 수 없습니다.

세 개의 Plan 제품 그룹은 모두 동일한 기본 객체(work item)를 사용할 것입니다. 각 제품 그룹은 여전히 MAU를 추적해야 합니다.

제안된 집계 카운터 스키마

graph TD Event[구체적 상호작용 카운터] --> AC[집계 카운터] AC --> Plan[Plan xMAU] AC --> PM[Project Management xMAU] AC --> PP[Product Planning xMAU] AC --> Cer[Certify xMAU] AC --> WI[작업 항목 사용자]

구현

새로운 집계 스키마는 이미 구현되었으며 GitLab.com에서 작업 항목의 고유한 동작을 이미 추적하고 있습니다.

구현 세부 정보는 MR를 참고할 수 있습니다. 해당 MR은 새로운 고유 동작의 정의, 코드에서 이벤트 추적 및 필요한 집계 카운터에 새로운 고유 동작을 추가하는 내용을 다룹니다.

관련 주제