도전과제
작업 항목 용어
요구 사항 및 에픽을 작업 항목 유형으로 마이그레이션
- 요구 사항을 작업 항목 유형으로 마이그레이션
- 에픽을 작업 항목 유형으로 마이그레이션
Work item, work item type, 및 위젯 로드맵
Redis HLL Counter Schema
- 제안된 집계 카운터 스키마
- 구현

작업 항목 및 작업 항목 유형

도전과제

이슈는 협업을 위한 중앙 집중식 허브로 기능할 수 있는 잠재력을 갖고 있습니다. 다른 이슈 유형은 수행해야 하는 작업에 따라 다양한 필드와 다른 맥락이 필요합니다. 예를 들어 다음과 같습니다.

버그는 재현 단계를 기술해야 합니다.
사건은 스택 추적과 해당 사건에만 관련되는 기타 맥락 정보를 참조해야 합니다.

각 개체 유형이 별도의 모델로 발전하는 대신, 우리는 해당 객체를 사용하여 커스터마이즈할 수 있는 기본적인 공통 모델을 표준화할 수 있습니다.

현재 이슈 사용에 대한 일부 문제와 작업 항목을 살펴보는 이유는 다음과 같습니다.

이슈 유형을 표시하기 위해 레이블을 사용하는 것은 번거롭고 보고 뷰를 복잡하게 만듭니다.
이슈 유형은 레이블 사용의 최상위 두 가지 사용 사례 중 하나이므로 이를 지원하는 것이 합리적입니다.
우리가 이슈에 더 많은 기능을 추가함에 따라 이슈가 지저분해지고, 완벽하지 않습니다.
- 다른 객체와의 관계를 표출하는 일관된 패턴이 없습니다.
- 레이블을 사용하기 때문에 서로 다른 유형의 이슈에 걸친 일관된 상호 작용 모델이 없습니다.
- 이슈 유형의 여러 구현은 유연성과 확장성이 부족합니다.
에픽, 이슈, 요구 사항 등은 모두 상호 작용에는 유사하지만 다소 차이가 있어 사용자는 각각의 행동 방식에 복잡한 정신적 모델을 유지해야 합니다.
이슈는 지원해야 할 새로운 작업이 필요로 하는만큼 확장성이 부족합니다.
코드베이스의 유지 가능성과 기능 개발은 이슈 추적의 핵심 역할 이상으로 발전시킬 때 더 큰 도전 과제가 됩니다.
일반적인 상호 작용을 통해 기능을 구현할 때 보통 처음부터 만들어진 객체에 코드를 가져오게 됩니다. 이로 인해 중복된 작업이 발생하며 궁극적으로 공통 상호 작용 사이에 작은 차이가 발생합니다. 이는 일관성 없는 사용자 경험으로 이어집니다.

작업 항목 용어

혼란을 피하고 효율적인 커뮤니케이션을 보장하기 위해 작업 항목을 논의할 때는 오로지 다음 용어만 사용합니다. 이 디렉터리은 작업 항목 용어의 단일 진실 공급원(SSoT)입니다.

용어	설명	오용 예	바르게 표현하면
작업 항목 유형	작업 항목의 클래스; 예: 이슈, 요구 사항, 테스트 케이스, 사건, 또는 작업	에픽은 결국 이슈가 될 것이다	에픽은 결국 작업 항목 유형이 될 것이다
작업 항목	작업 항목 유형의 인스턴스
작업 항목 화면	모든 유형의 작업 항목을 렌더링하는 새 프론트엔드 뷰	새 뷰에서 렌더링되어야 합니다	작업 항목 화면에 렌더링되어야 합니다
기존 객체 모델	작업 항목 유형으로 변환된 또는 변환될 객체	에픽은 독립/옛날/이전 객체에서 작업 항목 유형으로 이전될 것이다	에픽은 기존 객체 모델에서 작업 항목 유형으로 변환될 것이다
레거시 이슈 화면	현재 이슈와 사건을 렌더링하는 기존 뷰	이슈는 여전히 이전 뷰에서 렌더링된다	이슈는 여전히 레거시 이슈 뷰에서 렌더링된다
이슈	기존 이슈 모델
이슈 가능	이슈 가능 모듈을 현재 사용중인 모든 모델 (이슈, 에픽 및 MRs)	사건은 issuable이다	사건은 작업 항목 유형이다
위젯	특정 작업 항목 데이터를 표시하거나 상호 작용할 수 있게 하는 UI 요소

과거에는 사용되던 몇 가지 용어가 혼란스럽게 사용되었고 현재는 권장되지 않습니다.

용어	설명	오용 예	바르게 표현하면
이슈 유형	작업 항목의 클래스를 가리키는 이전 방식	작업은 이슈 유형이다	작업은 작업 항목 유형이다

이전 전략

WI 모델은 기존 이슈 모델을 기반으로 구축되며 이슈 모델 코드를 점진적으로 WI 모델로 이전할 것입니다.

이를 처리하는 한 가지 방법은 다음과 같습니다.

class WorkItems::WorkItem < ApplicationRecord
  self.table_name = 'issues'
  
  # ... 모든 현재 이슈.rb 코드
end

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

우리는 이미 이슈 테이블 내에서 이슈 유형 개념을 사용하고 있습니다. 이슈, 사건 및 테스트 케이스 이슈 유형이 있습니다. 이를 확장하여 미래에 사용자가 사용자 정의 WITs를 정의할 수 있도록하려면 이슈 유형을 별도의 테이블, 작업 항목 유형으로 이동할 것입니다. 이슈 유형을 작업 항목 유형으로 이전하는 마이그레이션 프로세스는 이 이픽에서 설명된 대로 모든 루트 레벨 그룹을 위해 WIT 세트를 만드는 과정을 포함합니다.

먼저 WIT를 루트 레벨 그룹에서만 정의할 수 있게 하고, 그런 다음 하위 그룹에서 상속하게 할 것입니다. 나중에 하위 그룹에서 새 WIT를 정의할 수 있는 가능성에 대해 조사할 것입니다.

`work_item_types` 테이블 소개

예를 들어, ID가 11, 12, 13인 세 개의 루트 레벨 그룹이 있다고 가정해 보겠습니다. 또한, 다음과 같은 기본 유형이 있다고 가정해보겠습니다: 이슈: 0, 사건: 1, 테스트 케이스: 2.

해당하는 work_item_types 레코드:

`namespace_id`	`base_type`	`title`
11	0	이슈
11	1	사건
11	2	테스트 케이스
12	0	이슈
12	1	사건
12	2	테스트 케이스
13	0	이슈
13	1	사건
13	2	테스트 케이스

이를 달성하기 위해 우리가 할 일:

이슈 테이블에 작업 항목 유형 ID 열을 추가합니다.
새로 생성하거나 업데이트된 이슈에 대해 이슈 유형 및 작업 항목 유형 ID 열 모두에 기록하도록 합니다.
작업 항목 유형 ID 열을 백필하여 이슈의 프로젝트 루트 그룹에 해당하는 work_item_types#id를 가리키도록 합니다. 예를 들어:
```
issue.project.root_group.work_item_types.where(base_type: issue.issue_type).first.id.
```
이슈의 작업 항목 유형 ID가 채워지면, 쿼리를 이슈 유형 대신에 작업 항목 유형 ID를 사용하도록 전환할 수 있습니다.

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

위의 프로세스의 첫 번째 단계를 따릅니다. 여전히 모든 루트 레벨 그룹에 대해 새 WIT를 추가하는 마이그레이션을 실행해야 하므로 이 흐름은 모든 사용자에게 이용 가능한 WIT를 만들어야 한다는 점을 고려해야 합니다. 오랜 시간이 걸리는 마이그레이션 외에도 work_item_types에 대량의 레코드를 삽입해야 해서, 이는 사용자가 원하지 않거나 필요하지 않을 수 있습니다.
특정 루트 레벨 그룹의 work_item_types에 대한 레코드는 고객이 선택하는 경우에만 생성되도록 선택할 수 있습니다. 그러나 이것은 새로 도입된 작업 항목 유형의 발견 가능성이 낮아짐을 의미합니다.

작업 항목 유형 위젯

위젯은 작업 항목에 존재할 수 있는 단일 컴포넌트입니다. 이 컴포넌트는 하나 이상의 작업 항목 유형에서 사용될 수 있으며 구현 시 가벼운 사용자 정의가 가능합니다.

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

위젯은 그들의 목적에 의해 구분되어야 합니다. 가능한 한 이 목적은 최대한 높은 수준으로 추상화되어 재사용성을 극대화해야 합니다. 예를 들어 “작업”을 관리하는 위젯은 “하위 항목”으로 구축되었습니다. 하나의 하위 항목을 관리하는 대신, 이것은 모든 하위 항목을 관리하는 것으로 추상화되었습니다.

모든 WIT(작업 항목 유형)은 미리 정의된 위젯 풀을 공유하며 특정 WIT에서 활성화된 위젯으로 사용자 정의됩니다. 모든 속성(열 또는 연결)은 소속된 WIT과 관계없이 자체 기능을 갖는 위젯이 됩니다. 어떤 WIT이든 어떤 위젯이든 가질 수 있기 때문에 특정 WIT에 대해 활성화된 위젯을 정의하기만 하면 됩니다. 따라서 특정 작업 항목 유형으로 전환한 후에는 다른 집합의 위젯을 표시합니다.

위젯 메타데이터

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

목적은 GitLab이 고객을 위해 다양한 작업 항목 체계를 구현하는 데(의견이 있는 GitLab 워크플로 또는 SAFe 5 등) 또한 고객이 자체 워크플로를 사용자 정의하는 데 매우 유연하게 구성할 수 있는 것입니다.

이 경우, 작업 항목 체계는 특정 특성(일부 위젯이 활성화되고 다른 것은 아님)을 가진 유형 세트로 정의됩니다(예: Epic, Story, Bug, Task 등).

우리가 새로운 작업 항목 아키텍처를 구축하는 동안, 매우 유연한 방식으로 이러한 다양한 유형을 정의할 수 있는 능력을 구축하고 싶습니다. GitLab이 처음에 이 시스템을 사용하게 함으로써(고객 사용자 정의를 도입하지 않고) 초기 시스템을 더 잘 구축할 수 있습니다.

작업 항목의 base_type은 각 유형에 대해 사용할 수 있는 위젯을 정의하는 데 사용되며 이 정의는 데이터베이스 테이블에 저장되어야 합니다. WIT 위젯 메타데이터의 정확한 구조는 아직 정의되어야 합니다. base_type은 다른 유형의 리소스(요구 사항 및 사건)을 작업 항목으로 변환하는 데 도움이 될 것입니다. 최종적으로(이러한 리소스가 일반적인 작업 항목이 되면), base_type은 제거될 것입니다.

WIT 위젯의 아키텍처가 확정되기 전까지 새로운 작업 항목 유형을 만드는 것을 유보하고 있습니다. 새로운 작업 항목 유형이 절대적으로 필요한 경우 프로젝트 관리 엔지니어링 팀의 구성원에게 연락하십시오.

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

이슈 테이블의 issue_type 열을 제거하여 새 work_item_types 테이블을 사용하도록 변경을 완료했습니다(이 epic 참조).

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

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

다음 MR(Merge Request)은 새로운 work_item_types을 도입하는 방법을 보여줍니다:

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

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

마이그레이션을 작성할 때 다음을 기억해 주십시오:

중요: 기존 API에서 새로운 유형을 제외합니다.
- 아마도 우리는 새로 만들어진 이 유형의 작업 항목이 기존 기능(예: 이슈 디렉터리)에 표시되는 것을 원치 않을 것입니다. 따라서 마이그레이션이 실행될때까지 새 유형을 이 제외 디렉터리에 추가해야 합니다. 이 마이그레이션이 실행되자마자 사용자가 새 유형의 이슈 및 작업 항목을 생성할 수 있다면 이 과정은 생략할 수 있습니다.
regular migrations를 사용합니다.
- 새로운 작업 항목 유형을 추가하기 위해 정규 마이그레이션을 사용하는 것이 유익할 것이라고 믿습니다. 이렇게 하면 유형이 생성된다는 가정하에 이어지는 MR들은 다음 릴리즈를 기다리지 않고 즉시 이루어질 수 있습니다.
마이그레이션은 실패할 가능성을 피합니다.
- work_item_types과 관련된 데이터가 마이그레이션 실행 시 특정 상태로 있을 것으로 기대됩니다. 현재, 우리는 데이터를 확인하고 일관성 없는 상태에서 발견되어도 실패하지 않는 마이그레이션을 작성하는 것으로 예상합니다. 시드와 마이그레이션을 기반으로 한 데이터 상태에 얼마나 의존할 수 있는지에 대한 논의가 이 이슈에서 진행 중입니다. 데이터가 일관성 없는 상태에 있을 때 마이그레이션이 실패하지 않도록 마이그레이션을 작성해야합니다. 이러한 변경 사항을 위해 데이터베이스 작업을 업데이트해야할 수 있습니다.
새 유형에 대한 위젯 정의를 추가합니다.
- 이 마이그레이션은 모든 작업 항목이 필요한 위젯 정의와 함께 새로운 작업 항목 유형을 추가합니다. 선택하는 위젯은 새 작업 항목이 지원하는 기능에 따라 다릅니다. 그러나 Description과 같이 아마도 모든 새로운 작업 항목이 필요로 할 것으로 예상되는 몇 가지가 있습니다.
선택사항. 계층 제한 생성
- 예시 MR 중 하나에서는 work_item_hierarchy_restrictions 테이블에 레코드를 삽입하기도 합니다. 이는 새로운 작업 항목 유형이 Hierarchy 위젯을 사용할 것이라면 필요합니다. 이 테이블에서는 어떤 작업 항목 유형이 자식을 가질 수 있는지, 무슨 유형의 자식을 가질 수 있는지를 추가해야 합니다. 또한 동일한 유형의 작업 항목에 대한 계층 깊이를 지정해야 합니다. 기본적으로 새로운 제한을 생성할 때 교차 계층(교차 그룹 또는 프로젝트) 관계가 비활성화되어 있지만, cross_hierarchy_enabled에 값을 지정하여 활성화할 수 있습니다. 제한은 해당 작업 항목 유형의 캐시에 있기 때문에 연관된 작업 항목 유형에서 clear_reactive_cache!를 호출하는 것도 필요합니다.

선택사항. 연결된 항목 제한 생성

Linked items 위젯도 소스 유형이 다른 유형과 관련이 가능한지 또는 차단할 수 있는지를 정의하는 규칙을 지원합니다. 제한은 소스 유형이 연관될 수 있는지 또는 대상 유형을 차단할 수 있는지를 지정할 수 있습니다. 현재 제한 사항:

유형	연관될 수 있는 유형	차단할 수 있는 유형	차단될 수 있는 유형
Epic	Epic, 이슈, 작업, 목표, 주요 결과	Epic, 이슈, 작업, 목표, 주요 결과	Epic, 이슈, 작업
이슈	Epic, 이슈, 작업, 목표, 주요 결과	Epic, 이슈, 작업, 목표, 주요 결과	Epic, 이슈, 작업
작업	Epic, 이슈, 작업, 목표, 주요 결과	Epic, 이슈, 작업, 목표, 주요 결과	Epic, 이슈, 작업
목표	Epic, 이슈, 작업, 목표, 주요 결과	목표, 주요 결과	Epic, 이슈, 작업, 목표, 주요 결과
주요 결과	Epic, 이슈, 작업, 목표, 주요 결과	목표, 주요 결과	Epic, 이슈, 작업, 목표, 주요 결과

티켓 작업 항목 추가 예시

데이터베이스에는 티켓 작업 항목 유형이 이미 있지만, 이를 마이그레이션 예시로 사용하겠습니다. 새로운 유형의 경우 새 이름과 ENUM 값이 필요합니다.

class AddTicketWorkItemType < Gitlab::Database::Migration[2.1]
  disable_ddl_transaction!
  restrict_gitlab_migration gitlab_schema: :gitlab_main
  
  ISSUE_ENUM_VALUE = 0
  # Enum value comes from the model where the enum is defined in
  # https://gitlab.com/gitlab-org/gitlab/-/blob/1253f12abddb69cd1418c9e13e289d828b489f36/app/models/work_items/type.rb#L30.
  # A new work item type should simply pick the next integer value.
  TICKET_ENUM_VALUE = 8
  TICKET_NAME = '티켓'
  # Widget definitions also have an enum defined in
  # https://gitlab.com/gitlab-org/gitlab/-/blob/1253f12abddb69cd1418c9e13e289d828b489f36/app/models/work_items/widget_definition.rb#L17.
  # We need to provide both the enum and name as we plan to support custom widget names in the future.
  TICKET_WIDGETS = {
    '담당자' => 0,
    '설명' => 1,
    '계층 구조' => 2,
    '라벨' => 3,
    '마일스톤' => 4,
    '노트' => 5,
    '시작일 및 마감일' => 6,
    '상태' => 7,
    '가중치' => 8,
    '반복' => 9,
    '알림' => 14,
    '현재 사용자 할 일' => 15,
    '수상 이모티콘' => 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('이슈 작업 항목을 찾을 수 없어 계층 제약 조건 생성을 건너뜁니다') unless issue_type
    
    # This part of the migration is only necessary if the new type uses the `Hierarchy` widget.
    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
    # There's the remote possibility that issues could already be
    # using this issue type, with a tight foreign constraint.
    # Therefore we will not attempt to remove any data.
  end
end

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

BaseTypeImporter는 각 유형의 구조와 해당 유형에 연결된 위젯을 명확하게 시각화할 수 있는 위치입니다. BaseTypeImporter는 신설 GitLab 설치 및 테스트 스위트의 근원지로 사용됩니다. 이는 항상 마이그레이션으로 변경된 사항을 반영해야 합니다.

사용자 정의 작업 항목 유형

WIT 위젯 메타데이터 및 WIT를 특정 위젯에 매핑하는 워크플로우로 사용자가 사용자 정의 WIT를 노출시킬 수 있을 것입니다. 사용자는 자신만의 WIT를 생성하고 미리 정의된 풀에서 위젯을 사용자 정의할 수 있을 것입니다.

사용자 정의 위젯

최종 목표는 사용자가 사용자 정의 위젯을 정의하고 이러한 사용자 정의 위젯을 모든 WIT에서 사용할 수 있도록 하는 것입니다. 하지만 이는 훨씬 더 나은 반복이며 사용될 데이터와 애플리케이션 아키텍처를 결정하기 위한 추가 조사가 필요합니다.

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

우리는 요구 사항과 에픽을 해당하는 위젯의 집합과 함께 작업 항목 유형으로 마이그레이션할 것입니다. 이를 위해 데이터를 이슈 테이블로 마이그레이션하고 현재의 요구 사항 및 에픽 테이블은 예전 참조용으로 유지하여 기존의 참조와의 하위 호환성을 보장할 것입니다.

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

현재 요구 사항 속성은 주로 이슈 속성의 하위 집합이므로, 마이그레이션은 주로 다음과 같습니다. - 데이터 마이그레이션. - API 수준에서 역호환성 유지. - 예전 참조가 계속 작동하도록 보장.

다른 기본 데이터 구조로의 마이그레이션은 최종 사용자에게는 신경 쓰지 않아야 합니다.

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

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

주요 누락된 기능은 다음과 같습니다. - 작업 항목을 그룹 수준에서 가져오기. 이는 그룹 및 프로젝트 통합 계획에 따라 달려 있습니다. - 계층 구조 위젯: 작업 항목을 계층 구조로 구조화할 수 있는 기능. - 상속된 날짜 위젯.

이미 에픽을 사용 중인 사용자들의 워크플로우를 방해하지 않기 위해, 프로젝트 수준에서 에픽과 기능 동등성을 제공하는 ‘피처’라는 새로운 WIT를 도입할 것입니다. 그것이 그룹 및 프로젝트 통합의 진행과 결합됨으로써 에픽을 WIT로의 원활한 마이그레이션 경로를 최소한의 방해로 제공할 수 있을 것입니다.

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

우리는 업무 항목, 업무 항목 유형 및 사용자 정의 위젯(CW)으로 점진적인 과정으로 나아갈 것입니다. 저희의 앞으로의 업무 개요를 대략적으로 알아보려면 epic 6033을 참조하세요.

Redis HLL Counter Schema

저희는 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은 새로운 고유한 작업의 정의, 코드에서의 이벤트 추적, 그리고 필요한 집계 카운터에 새로운 고유한 작업을 추가하는 것을 다루고 있습니다.

작업 항목 및 작업 항목 유형

도전과제

작업 항목 용어

이전 전략

`work_item_types` 테이블 소개

작업 항목 유형 위젯

위젯 메타데이터

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

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

티켓 작업 항목 추가 예시

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

사용자 정의 작업 항목 유형

사용자 정의 위젯

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

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

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

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

Redis HLL Counter Schema

제안된 집계 카운터 스키마

구현

도움말

기능 사용 가능성과 제품 평가판

도움받기

작업 항목 및 작업 항목 유형

도전과제

작업 항목 용어

이전 전략

work_item_types 테이블 소개

작업 항목 유형 위젯

위젯 메타데이터

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

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

티켓 작업 항목 추가 예시

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

사용자 정의 작업 항목 유형

사용자 정의 위젯

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

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

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

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

Redis HLL Counter Schema

제안된 집계 카운터 스키마

구현

도움말

기능 사용 가능성과 제품 평가판

도움받기

`work_item_types` 테이블 소개