def timestamp_projection
  # 여기에 타임스탬프 표현을 입력하세요
end

def object_type
  이슈
end

def timestamp_projection
  IssueMetrics.arel_table[:first_mentioned_in_commit_at]
end

def apply_query_customization(query)
  # 이 경우 쿼리 속성은 Issue 모델을 기반으로 함: `Issue.where(...)`
  query.joins(:metrics)
end

graph LR; 이슈생성 --> 이슈종료; 이슈생성 --> 첫번째 게시판에 추가된 이슈; 이슈생성 --> 마일스톤과 처음으로 연결된 이슈; 이슈생성 --> 커밋에서 처음 언급된 이슈; 이슈생성 --> 마지막으로 편집된 이슈; 이슈생성 --> 라벨이 추가된 이슈; 이슈생성 --> 라벨이 제거된 이슈; 이슈생성 --> 처음으로 할당된 이슈; Merge요청생성 --> Merge된 Merge Request; Merge요청생성 --> Merge Request 닫힘; Merge요청생성 --> 처음으로 프로덕션에 배포된 Merge Request; Merge요청생성 --> 마지막으로 빌드가 시작된 Merge Request; Merge요청생성 --> 마지막으로 빌드 완료된 Merge Request; Merge요청생성 --> 마지막으로 편집된 Merge Request; Merge요청생성 --> 라벨이 추가된 Merge Request; Merge요청생성 --> 라벨이 제거된 Merge Request; Merge요청생성 --> 처음으로 할당된 Merge Request; 처음으로 할당된 Merge요청 --> Merge Request 닫힘; 처음으로 할당된 Merge요청 --> 마지막으로 빌드가 시작된 Merge Request; 처음으로 할당된 Merge요청 --> 마지막으로 편집된 Merge Request; 처음으로 할당된 Merge요청 --> Merge된 Merge Request; 처음으로 할당된 Merge요청 --> 라벨이 추가된 Merge Request; 처음으로 할당된 Merge요청 --> 라벨이 제거된 Merge Request; 마지막으로 빌드가 시작된 Merge요청 --> 마지막으로 빌드가 완료된 Merge Request; 마지막으로 빌드가 시작된 Merge요청 --> Merge Request 닫힘; 마지막으로 빌드가 시작된 Merge요청 --> 처음으로 프로덕션에 배포된 Merge Request; 마지막으로 빌드가 시작된 Merge요청 --> 마지막으로 편집된 Merge Request; 마지막으로 빌드가 시작된 Merge요청 --> Merge된 Merge Request; 마지막으로 빌드가 시작된 Merge요청 --> 라벨이 추가된 Merge Request; 마지막으로 빌드가 시작된 Merge요청 --> 라벨이 제거된 Merge Request; Merge된 Merge요청 --> 처음으로 프로덕션에 배포된 Merge Request; Merge된 Merge요청 --> Merge Request 닫힘; Merge된 Merge요청 --> 처음으로 프로덕션에 배포된 Merge Request; Merge된 Merge요청 --> 마지막으로 편집된 Merge Request; Merge된 Merge요청 --> 라벨이 추가된 Merge Request; Merge된 Merge요청 --> 라벨이 제거된 Merge Request; 이슈에 라벨이 추가됨 --> 이슈에 라벨이 추가됨; 이슈에 라벨이 추가됨 --> 이슈에 라벨이 제거됨; 이슈에 라벨이 추가됨 --> 이슈종료; 이슈에 라벨이 추가됨 --> 처음으로 할당된 이슈; 이슈에 라벨이 제거됨 --> 이슈종료; 이슈에 라벨이 제거됨 --> 처음으로 할당된 이슈; 처음으로 게시판에 추가된 이슈 --> 이슈종료; 처음으로 게시판에 추가된 이슈 --> 마일스톤과 처음으로 연결된 이슈; 처음으로 게시판에 추가된 이슈 --> 커밋에서 처음 언급된 이슈; 처음으로 게시판에 추가된 이슈 --> 마지막으로 편집된 이슈; 처음으로 게시판에 추가된 이슈 --> 라벨이 추가된 이슈; 처음으로 게시판에 추가된 이슈 --> 라벨이 제거된 이슈; 처음으로 게시판에 추가된 이슈 --> 처음으로 할당된 이슈; 처음으로 할당된 이슈 --> 이슈종료; 처음으로 할당된 이슈 --> 처음으로 게시판에 추가된 이슈; 처음으로 할당된 이슈 --> 마일스톤과 처음으로 연결된 이슈; 처음으로 할당된 이슈 --> 커밋에서 처음 언급된 이슈; 처음으로 할당된 이슈 --> 마지막으로 편집된 이슈; 처음으로 할당된 이슈 --> 라벨이 추가된 이슈; 처음으로 할당된 이슈 --> 라벨이 제거된 이슈; 마일스톤과 처음으로 연결된 이슈 --> 이슈종료; 마일스톤과 처음으로 연결된 이슈 --> 처음으로 게시판에 추가 ## 기본 단계 [원래 구현](https://gitlab.com/gitlab-org/gitlab/-/issues/847)에서 값 스트림 분석의 7단계가 정의되었습니다. 이러한 단계는 항상 각 상위에 대해 사용 가능하지만, 이러한 단계를 변경하는 것은 불가능합니다. 작업을 효율적으로 하고 생성된 레코드 수를 줄이기 위해 기본 단계는 인메모리 객체로 표현됩니다(지속되지 않음). 사용자가 처음으로 사용자 정의 단계를 만드는 경우 모든 단계가 지속됩니다. 이 동작은 값 스트림 분석 서비스 객체에 구현되어 있습니다. 이것의 이유는 나중에 단계를 숨기고 정렬하는 기능을 추가하고자 했기 때문입니다. ## 데이터 수집기 `DataCollector`는 데이터가 데이터베이스에서 쿼리되는 중심 지점입니다. 이 클래스는 항상 단일 단계에서 작동하며 다음 컴포넌트로 구성됩니다. - `BaseQueryBuilder`: - 초기 쿼리 작성을 담당합니다. - `Stage`별 구성: 이벤트 및 사용자 정의 쿼리 구성. - UI에서 오는 매개변수: 날짜 범위. - `Median`: `BaseQueryBuilder`의 쿼리를 사용하여 단계에 대한 중앙값 기간을 계산합니다. - `RecordsFetcher`: `BaseQueryBuilder`의 쿼리 및 가시성 규칙을 적용하기 위해 특정 `Finder` 클래스를 사용하여 단계에 대한 관련 레코드를 로드합니다. - `DataForDurationChart`: 산포도 차트에 마무리 시간(종료 이벤트 타임스탬프)과 함께 계산된 기간을 로드합니다. 새로운 계산 또는 쿼리를 지원하려면 `DataCollector` 클래스에 새로운 메서드 호출로 구현하십시오. 집계 값 스트림 분석 백엔드를 지원하기 위해 이러한 클래스들은 [`집계된`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/analytics/cycle_analytics/aggregated) 네임스페이스 내에서 다시 구현되었습니다. ### 데이터베이스 쿼리 백엔드 VSA는 두 가지 백엔드를 지원합니다: [집계](value_stream_analytics/value_stream_analytics_aggregated_backend.md) 및 "라이브". 라이브 쿼리 백엔드는 어느 시점에서 폐기될 것으로 간주될 수 있습니다. - "라이브": 표준 `IssuableFinders`를 사용합니다. - 집계: 사전 집계된 데이터베이스 테이블에서 데이터를 쿼리합니다. ## 상위 수준 개요 - Rails 컨트롤러(`Analytics::CycleAnalytics` 모듈): 값 스트림 분석은 `analytics` 작업 영역 내에 구현된 JSON 엔드포인트를 통해 데이터를 노출시킵니다. 단계 구성 또한 JSON 엔드포인트(CRUD)에서 구현됩니다. - 서비스(`Analytics::CycleAnalytics` 모듈): 모든 `Stage` 관련 작업은 해당 서비스 객체로 위임됩니다. - 모델(`Analytics::CycleAnalytics` 모듈): 모델은 `Stage` 객체를 지속시키는 데 사용됩니다. - 피처 클래스(`Gitlab::Analytics::CycleAnalytics` 모듈): - 쿼리 작성 및 피처별 비즈니스 로직 정의를 담당합니다. - `DataCollector`, `Event`, `StageEvents` 등. ## 프론트엔드 [프로젝트 VSA](../user/group/value_stream_analytics/index.md)는 모든 사용자에게 제공되며 다음을 포함합니다: - 티어에 따라 키 및 DORA 메트릭의 혼합 사용. - [기본 단계](#default-stages) 세트 사용. [그룹 VSA](../user/group/value_stream_analytics/index.md)는 라이선스 사용자에게만 제공되며 다음을 포함합니다: - [개요 단계](https://gitlab.com/gitlab-org/gitlab/-/issues/321438). - 사용자 정의 값 스트림을 만들 수 있는 기능. 그룹 및 프로젝트 레벨 VSA 프론트엔드는 모두 Vue 및 Vuex로 프로덕션되었으며 유사한 패턴을 따릅니다: - `index.js` 파일은 URL 쿼리 매개변수를 추출하고 Vue 앱 및 Vuex 스토어를 생성하여 `initialize` Vuex 액션을 디스패치합니다. - `base.vue` 파일은 각 페이지, 메트릭, 필터, 차트 및 단계 테이블을 렌더링하는 데 사용됩니다. 그룹 VSA Vuex 스토어는 [Vuex 모듈](https://vuex.vuejs.org/guide/modules.html)을 사용하여 차트 렌더링에 사용되는 일부 상태와 로직을 분리합니다. ### 공유 컴포넌트 단계 테이블 및 경로와 같은 일부 UI는 프로젝트 VSA 및 그룹 VSA 간에 공유됩니다. 이러한 공유 컴포넌트는 프로젝트 VSA 디렉터리 `app/assets/javascripts/cycle_analytics/components`에 있으며 필요한 경우 그룹 레벨 VSA에 포함됩니다. 그룹 레벨 기능을 위한 모든 프론트엔드 코드는 `ee/app/assets/javascripts/analytics/cycle_analytics/components`에 위치합니다. ## 테스트 많은 이벤트와 가능한 페어링이 있기 때문에 각 페어링을 테스트하는 것은 불가능합니다. 각 페어링에 대해 한 가지 이상의 테스트 케이스가 있는 것이 규칙입니다. 새로운 `Event`를 사용하여 단계에 대한 테스트 케이스를 작성하는 것은 데이터를 두 번 생성해야 하기 때문에 어려울 수 있습니다. 이를 약간 단순화하기 위해 각 테스트 케이스는 `DataCollector`를 통해 구현되어야 하며 다음 사항을 다루는 여러 테스트로 전환되어야 합니다. - 다른 상위: `그룹` 또는 `프로젝트` - 다른 계산: `중앙값`, `RecordsFetcher` 또는 `DataForDurationChart` VSA 프론트엔드는 두 가지 다른 수준(통합, 단위)에서 철저하게 테스트됩니다. - 캐피바라 및 RSpec을 통해 실제 백엔드를 사용한 종단간 통합 테스트. - 사전 생성된 데이터 픽스처를 사용한 Jest 프론트엔드 테스트. ## 개발 설정 및 테스트 값 스트림 분석 실행은 [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit)를 통해 수행할 수 있습니다. 기본적으로 프로젝트-레벨(FOSS) 버전의 기능을 볼 수 있습니다. GDK가 실행 중인 경우 시드 스크립트를 실행하여 일부 데이터를 생성할 수 있습니다: ```shell SEED_CYCLE_ANALYTICS=true SEED_VSA=true FILTER=cycle_analytics rake db:seed_fu

Analytics::CycleAnalytics::ReaggregationWorker.new.perform