작업 항목 및 작업 항목 유형

GitLab의 작업 항목(Work Items) 아키텍처, 유형, 위젯, 마이그레이션 전략 및 계측 시스템을 설명합니다.

작업 항목(Work Items)은 GitLab의 이슈 추적 기능을 표준화하고 확장하는 유연한 모델을 도입합니다. 작업 항목을 사용하면 다양한 위젯으로 커스터마이즈할 수 있는 다양한 유형을 정의하여 버그, 인시던트, 테스트 케이스 또는 기타 작업 단위를 추적하는 등 특정 요구사항을 충족할 수 있습니다. 이 아키텍처 문서는 작업 항목 및 작업 항목 유형에 대한 개발 세부 사항과 구현 전략을 다룹니다. 앞으로 진행해야 할 작업의 대략적인 개요는 에픽 6033 을 참조하세요. 과제 # 이슈는 협업을 위한 중앙 허브가 될 가능성이 있습니다. 각기 다른 이슈 유형은 어떤 작업을 수행하는 데 사용되는지에 따라 서로 다른 필드와 맥락이 필요하다는 사실을 받아들여야 합니다. 예를 들어: 버그에는 재현 단계를 나열해야 합니다. 인시던트에는 스택 트레이스 참조와 해당 인시던트에만 관련된 기타 맥락 정보가 필요합니다. 각 객체 유형이 별도의 모델로 분기되는 대신, 포함하는 위젯(하나 이상의 속성)으로 커스터마이즈할 수 있는 공통 기반 모델을 표준화할 수 있습니다. 현재 이슈 사용의 문제점과 작업 항목을 검토하는 이유는 다음과 같습니다: 라벨을 사용하여 이슈 유형을 표시하는 것은 번거롭고 보고 뷰를 더 복잡하게 만듭니다. 이슈 유형은 라벨의 상위 두 가지 사용 사례 중 하나이므로, 이를 위한 일급 지원을 제공하는 것이 합리적입니다. 더 많은 기능을 추가함에 따라 이슈가 혼잡해지기 시작했으며, 완벽하지 않습니다: 다른 객체와의 관계를 표시하는 방법에 일관된 패턴이 없습니다. 라벨을 사용하기 때문에 서로 다른 이슈 유형 간에 일관된 인터랙션 모델이 없습니다. 이슈 유형의 다양한 구현은 유연성과 확장성이 부족합니다. 에픽, 이슈, 요구사항 등은 공통 인터랙션에서 유사하지만 미묘한 차이가 있어 사용자가 각각의 동작 방식에 대한 복잡한 정신 모델을 유지해야 합니다. 이슈는 지원해야 할 새로운 작업들을 충분히 수용할 만큼 확장 가능하지 않습니다. Issue 유형을 이슈 추적의 핵심 역할을 넘어 다양한 작업 항목 유형을 지원하고 로직 및 구조 차이를 처리하는 방향으로 확장함에 따라 코드베이스 유지 관리 및 기능 개발이 더 큰 과제가 됩니다. 새로운 기능은 일반적으로 공유 관심사를 통해 이슈의 동작을 가져오는 일급 객체로 구현됩니다. 이는 중복된 노력으로 이어지고, 궁극적으로 공통 인터랙션 간에 작은 차이를 유발합니다. 이는 일관성 없는 UX로 이어집니다. 작업 항목 용어 # 혼란을 방지하고 효율적인 커뮤니케이션 을 보장하기 위해, 작업 항목에 대해 논의할 때 다음 용어만 사용합니다. 이 목록은 작업 항목 용어의 단일 진실 공급원(Single Source Of Truth, SSOT) 입니다. 용어 설명 잘못된 사용 예 올바른 표현 work item type 작업 항목의 클래스; 예: 이슈, 요구사항, 테스트 케이스, 인시던트, 태스크 에픽은 결국 이슈가 될 것이다 에픽은 결국 work item type이 될 것이다 work item work item type의 인스턴스 wo