작업 항목 개발

  • 작업 항목 목록은 그룹 수준에서만 사용할 수 있습니다 http://gdk.test:3000/groups/flightjs/-/work_items, 기능 플래그 namespace_level_work_items로 활성화되어 있습니다.

  • 새로운 작업 항목 UI는 프로젝트 수준에서 사용할 수 있습니다 http://gdk.test:3000/flightjs/Flight/-/work_items/new 기능 플래그 work_items_alpha를 활성화한 후 사용할 수 있습니다.

  • 작업 항목을 보기/편집할 수 있는 UI는 프로젝트 수준에서 사용할 수 있습니다 http://gdk.test:3000/flightjs/Flight/-/work_items/:iid 기능 플래그 work_items_alpha를 활성화한 후 사용할 수 있습니다.

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

도전 과제

이슈는 협업을 위한 중앙 집중식 허브가 될 수 있는 잠재력을 가지고 있습니다.

우리는 서로 다른 이슈 유형이 수행하는 작업에 따라 다른 필드와 다른 맥락을 요구한다는 사실을 받아들여야 합니다. 예를 들어:

  • 버그는 재현 단계 목록이 필요합니다.
  • 사건은 해당 사건과 관련된 스택 트레이스 및 기타 맥락 정보에 대한 참조가 필요합니다.

각 객체 유형이 별도의 모델로 분기되는 대신, 우리는 이를 사용자 정의할 수 있는 기본 공통 모델에 표준화할 수 있습니다.

다음은 현재 이슈 사용에 대한 몇 가지 문제와 우리가 작업 항목을 조사하고 있는 이유입니다:

  • 이슈 유형을 표시하기 위해 레이블을 사용하는 것은 번거롭고 리포팅 뷰를 더 복잡하게 만듭니다.

  • 이슈 유형은 레이블의 상위 두 사용 사례 중 하나입니다. 따라서 이들을 위해 일급 지원을 제공하는 것이 합리적입니다.

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

    • 다른 객체와의 관계를 표출하는 일관된 패턴이 없습니다.

    • 레이블을 사용함에 따라 서로 다른 유형의 이슈 간의 일관된 상호작용 모델이 없습니다.

    • 이슈 유형의 다양한 구현은 유연성과 확장성이 부족합니다.

  • 에픽, 이슈, 요건 및 기타 요소는 모두 유사하지만 미세하게 다르기 때문에 사용자가 각 요소의 동작 방식에 대한 복잡한 정신 모델을 유지해야 합니다.

  • 이슈는 그들이 촉진해야 하는 모든 emergent 작업을 지원할 수 있을 만큼 충분히 확장 가능하지 않습니다.

  • 코드베이스 유지 관리 및 기능 개발은이슈 유형이 추적 역할을 넘어서 다양한 작업 항목 유형을 지원하고 논리와 구조의 차이를 처리하면서 더 큰 도전이 됩니다.

  • 새로운 기능은 일반적으로 이슈에서 동작을 가져오는 일급 객체로 구현됩니다. 이는 중복 작업으로 이어지고 결과적으로 공통 상호작용 간의 작은 차이로 이어집니다. 이는 일관성 없는 UX로 이어집니다.

작업 항목 용어

혼란을 피하고 효율적인 커뮤니케이션을 보장하기 위해, 우리는 작업 항목에 대해 논의할 때 다음 용어를 독점적으로 사용할 것입니다. 이 목록은 작업 항목 용어에 대한 단일 진리 원천(SSoT)입니다.

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

과거에 사용되었던 일부 용어는 이제 혼란을 초래하고 discouraged 되었습니다.

용어 설명 오용 예시 유효해야 할
이슈 유형 작업 항목 클래스에 대한 이전의 표현 방식 작업은 이슈 유형입니다 작업은 작업 항목 유형입니다

마이그레이션 전략

WI 모델은 기존 Issue 모델 위에 구축되며, 우리는 점진적으로 Issue 모델 코드를 WI 모델로 마이그레이션할 것입니다.

접근하기 위한 한 가지 방법은 다음과 같습니다:

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

  # ... 현재 issue.rb 코드 모두
end

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

우리는 이미 issues 테이블 내에서 issue_type 열을 통해 WIT의 개념을 사용하고 있습니다. 이슈 유형으로는 issue, incident, test_case가 있습니다. 향후 사용자가 사용자 정의 WIT를 정의할 수 있도록 확장하기 위해, 우리는 issue_type을 별도의 테이블인 work_item_types로 이동할 것입니다. issue_type을 work_item_types로 마이그레이션하는 과정에는 이 에픽에 설명된 대로 모든 루트 수준 그룹에 대한 WIT 집합을 생성하는 것이 포함됩니다.

참고: 초기에는 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 열을 보충하여 문제의 프로젝트 루트 그룹에 해당하는 work_item_types#id를 가리키도록 합니다. 예를 들어:

    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에 대한 레코드는 고객이 선택할 때만 생성되도록 합니다. 그러나 이는 새로 도입된 작업 항목 유형의 발견 가능성이 낮아짐을 의미합니다.

작업 항목 유형 위젯

위젯은 작업 항목에 존재할 수 있는 단일 구성 요소입니다. 이 구성 요소는 하나의 작업 항목 유형이나 여러 작업 항목 유형에서 사용될 수 있으며, 구현 시 약간의 사용자 정의가 가능합니다.

위젯은 프론트엔드 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 위젯 아키텍처가 완료될 때까지 새로운 작업 항목 유형의 생성을 보류하고 있습니다. 새로운 작업 항목 유형이 반드시 필요하다면, 프로젝트 관리 엔지니어링 팀 구성원에게 연락하십시오.

데이터베이스에서 새 작업 항목 유형 만들기

우리는 issues 테이블에서 issue_type 열을 제거하여 새 work_item_types 테이블을 사용하는 방향으로 작업을 완료했습니다. 이 과정은 이 에픽에서 설명됩니다.

work_item_types 테이블 도입 이후, 우리는 더 많은 work_item_types를 추가하고 있으며, 다른 팀이 이를 더 쉽게 할 수 있도록 하고자 합니다. 새 work_item_type을 도입하기 위해서는 다음을 수행해야 합니다:

  1. work_item_types 테이블에 새 레코드를 만들기 위해 데이터베이스 마이그레이션을 작성합니다.
  2. Gitlab::DatabaseImporters::WorkItems::BaseTypeImporter를 업데이트합니다.

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

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

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

마이그레이션을 작성할 때 다음 사항을 염두에 두세요:

  • 중요: 기존 API에서 새로운 유형을 제외하십시오.
    • 우리는 이 유형의 새로 생성된 작업 항목이 기존 기능(예: 이슈 목록)에 표시되는 것을 제외하고 싶습니다. 이에 따라 우리는 이 제외 리스트에 새 유형을 추가해야 합니다. 마이그레이션이 실행되는 즉시 사용자가 새 유형으로 새 이슈와 작업 항목을 생성할 수 있을 것으로 예상된다면 제외 리스트에 추가하지 않아도 됩니다.
  • 정규 마이그레이션을 사용하십시오. 배포 후 마이그레이션은 사용하지 마세요.

    • 우리는 정규 마이그레이션을 사용하는 것이 새로운 작업 항목 유형을 추가하는 데 유익할 것이라고 믿습니다. 배포 후 마이그레이션 대신, 이렇게 하면 유형이 생성되는 새로운 후속 MR이 즉시 존재한다고 가정할 수 있습니다. 다음 릴리스를 기다릴 필요가 없습니다.

      중요: 정규 마이그레이션을 사용하기 때문에 두 가지를 반드시 확인해야 합니다:

      1. 정규 마이그레이션의 시간 지침을 초과하지 않도록 합니다.

      2. 마이그레이션이 역호환 가능해야 합니다. 이는 배포된 코드가 이 마이그레이션을 도입한 MR이 롤백되고 마이그레이션이 적용되지 않더라도 계속 작동해야 함을 의미합니다.

  • 마이그레이션은 실패를 피해야 합니다.
    • 우리는 새로운 유형을 생성하는 마이그레이션을 실행할 때 work_item_types와 관련된 데이터가 특정 상태에 있어야 한다고 기대합니다. 현재 우리는 데이터가 일관되지 않은 상태에 있는 경우에도 실패하지 않도록 데이터 검사를 수행하는 마이그레이션을 작성합니다. 이 문제에 대한 논의가 있습니다. 데이터가 일관되지 않은 상태로 존재할 경우 실패하지 않도록 마이그레이션을 작성해야만 성공적인 파이프라인을 가질 수 있습니다. 이를 변경하기 위해 일부 데이터베이스 작업을 업데이트해야 할 필요가 있을 것입니다.
  • 새로운 유형에 대한 위젯 정의를 추가하십시오.
    • 마이그레이션은 새 작업 항목 유형과 각 작업 항목에 필요한 위젯 정의를 추가합니다. 선택하는 위젯은 새 작업 항목이 지원하는 기능에 따라 다르지만, Description과 같은 모든 새 작업 항목이 필요로 할 가능성이 있는 위젯이 있습니다.
  • 선택 사항. 계층 제한을 만듭니다.
    • 예제 MR 중 하나에서는 work_item_hierarchy_restrictions 테이블에 레코드를 삽입합니다. 이는 새 작업 항목 유형이 Hierarchy 위젯을 사용할 경우에만 필요합니다. 이 테이블에서는 어떤 작업 항목 유형이 자식을 가질 수 있는지와 그 유형의 자식의 깊이를 지정해야 합니다. 기본적으로 새로운 제한을 만들 때 크로스-계층(크로스 그룹 또는 프로젝트) 관계는 비활성화되어 있지만, cross_hierarchy_enabled에 값을 지정하면 활성화할 수 있습니다. 작업 항목 유형에 대한 제한이 캐시되므로 관련 작업 항목 유형에서 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 값을 사용해야 하므로 주의하세요.

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

  ISSUE_ENUM_VALUE = 0
  # Enum 값은 열거형이 정의된 모델에서 가져옵니다.
  # https://gitlab.com/gitlab-org/gitlab/-/blob/1253f12abddb69cd1418c9e13e289d828b489f36/app/models/work_items/type.rb#L30.
  # 새 작업 항목 유형은 단순히 다음 정수 값을 선택해야 합니다.
  TICKET_ENUM_VALUE = 8
  TICKET_NAME = 'Ticket'
  # 위젯 정의에도 enum이 정의되어 있습니다.
  # https://gitlab.com/gitlab-org/gitlab/-/blob/1253f12abddb69cd1418c9e13e289d828b489f36/app/models/work_items/widget_definition.rb#L17.
  # 향후 사용자 정의 위젯 이름을 지원할 계획이므로 enum과 이름을 모두 제공해야 합니다.
  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('이슈 작업 항목 유형을 찾을 수 없으므로 계층 제한 생성을 건너뜁니다.') 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 객체와 WIT 간의 기능 동등성을 제공해야 합니다.

주요 누락된 기능은 다음과 같습니다:

  • 작업 항목을 그룹 수준으로 가져오기. 이는 Consolidate Groups and Projects 이니셔티브에 의존합니다.
  • 계층 위젯: 작업 항목을 계층으로 구조화하는 기능.
  • 상속된 날짜 위젯.

에픽을 이미 사용하고 있는 사용자에게 작업 흐름을 방해하지 않기 위해, 우리는 프로젝트 수준에서 에픽과 기능 동등성을 제공하는 새로운 WIT인 Feature를 도입할 것입니다. 이를 Consolidate Groups and Projects와 결합하면 사용자 작업 흐름의 최소 방해로 에픽을 WIT로 매끄럽게 마이그레이션하는 경로를 제공하는 데 도움이 될 것입니다.

작업 항목, 작업 항목 유형, 및 위젯 로드맵

우리는 반복적인 프로세스에서 작업 항목, 작업 항목 유형 및 사용자 정의 위젯(CW)으로 나아갈 것입니다. 앞으로의 작업에 대한 대략적인 개요는 epic 6033를 참조하세요.

Redis HLL 카운터 스키마

우리는 Plan xMAU, Project Management xMAU, Certify xMAU 및 Product Planning xMAU를 포함한 작업 항목을 위한 더 확장 가능한 Redis 카운터 스키마가 필요합니다. 현재 Redis 슬롯 스키마로는 그룹 내 또는 단계 수준에서 기능 간 이벤트를 집계하고 중복 제거할 수 없습니다.

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

제안된 집계 카운터 스키마

graph TD Event[특정 상호작용 카운터] --> AC[집계 카운터] AC --> Plan[계획 xMAU] AC --> PM[프로젝트 관리 xMAU] AC --> PP[제품 계획 xMAU] AC --> Cer[인증 xMAU] AC --> WI[작업 항목 사용자]

구현

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

구현 세부사항은 이 MR을 참고할 수 있습니다.

이 MR은 새로운 고유 행동의 정의, 코드에서의 이벤트 추적 및 필요한 집계 카운터에 새로운 고유 행동을 추가하는 내용을 다룹니다.

관련 주제